Paint 1.99 (18-Sep-07)

The new Paint seems to work OK, and allow dragging of sprite icons, but the ‘create’ window background, and the background of the window containing the sprite icons, seem to have a problem with redrawing. It also has purple and black columns. This on RO 5.13 at 1280×1024x16M. Has anyone else seen this?

One for the bug tracker, maybe. Although I can’t reproduce what you’re seeing with RO 5.11. Do you have some filters getting in the way or something? What’s the output from *Filters?

No filters on start of rectangle draw or rectangle copy, or after work area fill or after icons plotted. On entry to Wimp_Poll Messenger Lite uses tbox_pre, Pinboard and Filer use FullNames, all tasks use ButtonBar. On exit from Wimp_Poll Messenger Lite uses tbox_post, the Filer uses SmartOpenDir, all tasks use IcnClipBrd, IClear, ButtonBar and DeepKeys, the Pinboard uses FullNames and the Filer uses FullNames.

Thanks for your feedback. I will start experimenting by removing the offending items from my boot sequence to see if it makes any difference.

The phenomenon persists even when there are no filters apart from DeepKeys. It is as if the sprite icon window is getting its background from the desktop and not being cleared.

Can’t reproduce the problem here (RO 5.13, 1600×1200 and 1280×1024, both 16M). But I see that Paint uses textured window backgrounds even if it’s turned off in Configure. Are you using a custom wimp sprite pool? Perhaps the tile sprite it wants is missing.

If you look at riscos.sources.apps.paint.c.main line 249 you’ll see the function that clears the background – main_clear_background.

I can’t remember exactly why I had a custom background clear I’ll have to look through the code to remind myself but I wouldn’t have done it if I thought it unnecessary. I think it’s something to do with flicker and the fact that you can’t use wimp_ploticon to plot the sprite making selecting awkward

main_clear_background should use either tile_1, tile_4, tile_8, etc sprite which should be visible in the resources.wimp.sprites file.

If it doesn’t find a sprite it should clear the screen.

If you know basic and C you should be able to test which part of main_clear_background isn’t working by translating the relevant parts to a BASIC test program.

The problem occurs when the tile sprite’s mode doesn’t match the screen’s mode.

Either a check for this should be added and if the modes don’t match a plain colour is used, or a different SpriteOp (56?) should be used to plot the tile sprite.

The main_clear_background function picks the tile which matches the mode.

Yes, it does, but if the tile isn’t in the mode it claims to be then the redraw failure occurs.

An example of this is tile_1-32 in the clear theme that comes with Chris Wraight’s Theme Manager. It should be 32bpp but is actually 16bpp.

It would be preferable if main_clear_background was altered so that it handles such tiles without redraw problems.

Ok.

Can someone who is having a problem download the fix at www.pdf.iconbar.com/paint199update.zip and confirm that it fixes things for them. I can then let ROOL have the changes.

The fix also uses a plain background if use textured backgrounds is not selected.

A quick test shows that the update seems to have fixed it. I’ll do some more experimenting later.

Thanks for the quick response.

I’m using Paint 1.99 on RISC OS 4.03 (VRPC). The selection model seems to have a few glitches, but I’d like to check these are also present on RO5 before entering them on to the bugs database.

- Sorting the sprites in file can result in random sprites being selected. These cannot be cleared without first selecting a non-selected sprite, then clicking on the window somewhere blank.

- On occasion, selecting a sprite doesn’t un-grey the ‘Copy’ and ‘Rename’ items on the menu. So you can’t copy or rename them! If you try and save this sprite out of the file, an ‘empty’ file is created, which causes a crash when you try and access it.

- Only Select seems to select a sprite. It might be worth adding Filer-like behaviour (i.e. Menu, clicked over a sprite, also selects it).

Are these observable by anyone else? A large file with a mix of 16bpp and optimised 256 colour sprites seems to produce the errors. If there’s interest, I’ll see if I can come up with a more exact set of circumstances when it happens.

Random selection of sprites after sorting occurs here as well (RO 5.11). It seems to happen when you sort the sprites when there’s one or more sprites selected.

Selecting a sprite with Menu works fine here. Make sure you click Menu over either the actual sprite or its name, not the space inbetween.

It is however a ‘hard’ selection rather than a ‘soft’ one like in the Filer. Which means the sprite won’t be deselected when you click Menu over another sprite. It would be nice if this could be altered.