Font paint oddity

I’m painting a line of text using Font_Paint with millipoint coordinates in a null event while dragging using Wimp_UpdateWindow. As soon as I start dragging the line of text starts bouncing up and down by 1 pixel.

If I print out the Font_Paint y coordinate to DADebug it shows that the y coordinate never changes but still the line of text bounces up and down.

If instead of outputting debug data to DADebug I output to Reporter the debug data still shows that the y coordinate never changes but now the line of text doesn’t bounce.

Anyone come across this before?

It appears its a problem with vertical sub-pixel anti-aliasing. If I disable it the text doesn’t bounce.

Both DAdebug & Reporter write to a circular memory buffer using a SWI, so I don’t see why they should affect the text differently.
I also have no suggestions why the text bounces!
What language are you using, and exactly how are you writing to DAdebug & Reporter? (send me a PM if you wish).

I don’t see it as a problem with reporter. I just found it odd that using reporter fixed the problem. It may have been because Reporter output text while I was painting whereas DADebug and no debugging doesn’t – If you see what I mean.

Yes that was the clue. Painting a space to 0,0 just before painting the line of text I want to paint stops the bouncing. So it looks like a bug in the operating system.

If you paint a space to 0,0 twice, does it then start bouncing again? What about a character other than space and possibly a random character each time? And finally, a character at a random position?

Sounds supiciously like something isn’t being reset between paints.

What about setting the graphics cursor to x,y prior to calling Font_Paint?

Changing the graphics cursor had no effect, neither did resetting the origin.

The text didn’t matter and repeating the line below had no effect. I ended up with preceding Font_Paint with

_swix(Font_Paint, _INR(0,4), font_handle, "", 0, 0, 0);

The problem only occurs with vertical sub-pixel anti-aliasing on. Having a different x coord didn’t matter only a different y coord is needed. I think it’s related to the choosing of the vertical sub-pixel rendering and the bounce is a wrongly chosen vertical position.

I think the bounce has been seen before. Alarm code has comments about working around the digital clock bouncing.

So the question is why does text plotted repeatedly at the same position bounce. The only explanation I can think of is I have a very vague recollection of something about the font manager caching values between Paint calls with the same y-coord – something to do with painting consecutive calls on the same line. The bounce looks like an error accumulator not being cleared between calls and eventually it rolls over and the sub-pixel position increases.

That theory must be a load of rubbish I can’t repeat the problem outside the desktop.

Ok I’ve done more investigating. It seems that if I don’t Font_Paint to 0,0 before painting the text that the font is painted differently depending on whether Wimp_RedrawWindow or Wimp_UpdateWindow is used.

The code keeps the window up to date with Wimp_RedrawWindow as normal but when dragging it uses Wimp_UpdateWindow to redraw the text at 2cs intervals.

Here are 2 snapshots. Snap1 is the text after a Wimp_RedrawWindow loop and Snap2 is the same text after a Wimp_UpdateWindow block. The text is drawn using exactly the same code other than the type of loop it is in.

The bouncing I experienced previously disappears if I quit Alarm. I have a digital clock showing seconds and I was getting a bounce every time the clock was redrawn – why? who knows.

When looking at the 2 snaps magnified you can see that the text is using a different vertical sub-pixel bitmap.

Where has this got me – absolutely nowhere. But you never know someone may find this useful.

The PRMs say that the Font Manager caches the last y coordinate painted to, but does not update the cached value on mode changes. If I’m understanding it correctly, that problem was fixed in RISC OS 3.1.

getting a bounce every time the clock was redrawn – why?

Alarm is switching output to a sprite, which is a bit like a mode change. I suspect the Font Manager needs to be updated to watch for Service_SwitchingOutputToSprite and correct the cached y coordinate.

Alarm is switching output to a sprite, which is a bit like a mode change. I suspect the Font Manager needs to be updated to watch for Service_SwitchingOutputToSprite and correct the cached y coordinate.

Would not be the first issue related switching output to sprites. I remember an issue with Ctugha, a DigitalCD full screen plugin. The song’s title is plotted into a black & white sprite which is in turn plotted on the 256 (usually rainbow like) colours screen to avoid anti-aliasing. As soon as I did that the screen started flashing. After some debugging I found out that restoring the output to the screen was not taking into account the fact that I used multiple screen banks.

I would suggest that the system maintain:
- Maintains separate VDU contexts for screen, sprite and printing so as not to corrupt variables when switching output.
- Issues a new Service_SwitchingDisplayContext on each switch so that modules keeping extra internal variables can adjust.

Thanks edwardx I new I’d seen something about caching the y coord. It’s at PRM 3-424.

I think the switching of the sprite in Alarm does reset the y coord because without alarm running the text is printed low and stays low. With Alarm running when the clock changes the text jumps back to the normal position then jumps back down implying that alarm is clearing the cached y position.

I wrote a simplified program which just kept writing the text to a window every 2cs using Wimp_UpdateWindow. With this test program running when I started dragging in the original program the original program no longer changed text position but the text in the test program did change position. If I cover the test program with another window so that the test program isn’t paining text the original programs text starts moving again – so Font painting in one program was affecting font painting in another program.

Anyway I modified the rom by changing Video.Render.Fonts.Manager.s.Fonts02 line 4175 from:

TEQ     R0,R14

to

TEQ     R0, #invalid_oldyco72

to stop the cached y coordinate being used and everything works fine.

So it looks like a ycoord caching issue.