Font rendering glitch with run windows (28-Oct-12 ROM, RC5 SD image) on RISC OS Pi?

Noticed a font rendering glitch running the 28-Oct-12 ROM with the RISC OS Pi RC5 SD image. (Haven’t updated to RC6 yet. I’ll probably wait for the official announcement before I do a fresh SD image.)

It looks like the font is trying to render as if it were on a yellow background, but the actual background is grey, in the title bar of a run window.

Yes, this is a known issue – something to do with the Wimp not fully liking the window furniture tool sprites.

I have seen this also at a title bar with blue in it and thought the background blending isn’t active at the RISC OS 5 Wimp Toolsprites (this bug is not at RISC OS 4).

Yes, it’s a bug caused by a new-ish feature of the Wimp that’s used by the new toolsprites added for the Raspberry Pi distro. This is the fact that the toolsprites don’t use a sprite mask, and use alternate sets of sprites depending upon whether the window has input focus or not.

While you get away with this in most cases, it breaks for applications that use non-standard window colours. It also breaks for a few special cases – command windows, error boxes and dialogue boxes hanging off menus – where the window colours have previously been tweaked to simulate the appearance of the window having / not having the input focus when the opposite is strictly the case. If you notice, the antialiasing is wrong on those windows too, with those toolsprites.

The problem is that the toolsprite plotting code, and the text plotting code, now disagree about what the dominant colour of the title bar is. One fix would be to turn on background blending, yes – but that has a redraw speed impact, especially on Iyonix, and also doesn’t address the problem with the Wimp’s special windows, or with unusual-coloured windows. I’d be tempted to say a better solution, rather than one set of sprites each for windows with and without the input focus, would be to follow the lead of the window background texture sprites, and allow one per Wimp colour, restoring the situation where the input focus state is only used to decide which of the window structure’s colour bytes to examine, rather than being used directly to decide which toolsprites to use. To avoid each toolsprite set having to have sets for all 16 colours, the tool tinting code could be re-enabled for the remaining colours, or there could be a catch-all sprite set which uses masked sprites to allow the background colour to show through in those cases.

I’d be tempted to say a better solution, rather than one set of sprites each for windows with and without the input focus, would be to follow the lead of the window background texture sprites, and allow one per Wimp colour,

Seconded. Have at it.

I have written nonsense:

I have seen this also at a title bar with blue in it and thought the background blending isn’t active at the RISC OS 5 Wimp Toolsprites (this bug is not at RISC OS 4).

As a User who had mostly used RISC OS 4/Select/6 I had thought that background blending is active as default in RISC OS 5. But if it is a speed issue at the Iyonix it makes sense to disable as default.
Now that I have activated it (Pandaboard ES) the desktop font looks great. And there is no problem with two toolsprite sets.

I like the two toolsprite set feature, so if someone doesn’t like it I advocate for a configurable feature. Either the two sprite sets or the ugly ;-) shown through background colour thing.