Ticket #417 (Fixed)Wed Jan 06 23:44:57 UTC 2016
Disc based SpriteExtend causes icon misplotting
| Reported by: | Sprow (202) | Severity: | Normal |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Fixed |
Details by Sprow (202):
SprExtend is present in the universal disc image for RISC OS 3.50 (though this observation is with it softloaded on RISC OS 4.02 as it happens).
The icon for NetSurf is not plotted correctly, is shown as a column of random colour pixels.
NetSurf has a check utility which is doing
IF sprextend < 0.99 THEN use !Sprites ELSE IF verify sprite area of alpha sprite = OK THEN use ASprites ELSE IF RISC OS 5 use 5Sprites ELSE use !Sprites ENDIF ENDIF ENDIFso is falling foul of the verify sprite area (that OS_SpriteOp is in SprExtend) which passes on the softloaded version. However, the Kernel rejects the sprite when later the Wimp or Filer wants to plot it. This can be seen by opening the sprite file – the non alpha sprites are shown, the file does not error on opening, but the alpha sprite is blank.
Perhaps for the softload case, just claim alpha sprites don’t exist? Or query the kernel to see if it’ll reject them, and decide based on that?
Changelog:
Modified by Jeffrey Lee (213) Tue, April 12 2016 - 12:46:01 GMT
The Wimp checks with both SpriteExtend and OS_ReadModeVariable to try and work out whether alpha sprites are supported (taking advantage of the fact that the kernel will treat unknown new-format sprites as 32bpp):
https://www.riscosopen.org/viewer/view/castle/R…
Possibly SpriteExtend should be modified to check each sprite mode word using OS_ReadModeVariable to make sure its idea of what the sprite should be like matches with what the kernel’s idea is (Log2BPP, NColour, eigen values, etc.)
Modified by Sprow (202) Wed, April 13 2016 - 08:09:11 GMT
I was thinking, like SprExtend checks for ColourTrans at startup, to do a single prod of the Kernel and retain a flag. Then report “Bad sprite” if asked and the kernel’s too old.
Of course a more finessed solution is even better, but this is probably a minority sport – we only provide SprExtend for its JPEG capabilities in the disc image, not to retrofit alpha sprites per se.
Modified by Sprow (202) Sat, January 20 2018 - 19:36:14 GMT
- Status changed from Open to Fixed
Concluded it was the ChkSprites utility that was wrong; SpriteExtend was correctly verifying a valid sprite area, but no check was being made that the Kernel could actually plot it.
Fixed in NetSurf 3.8 CI#4295.
