Ticket #397 (WontFix)Wed Sep 24 21:37:28 UTC 2014

I had a quick look at this last night, just enough to confirm “Yep, that’s a bug”. My guess is that when one of the objects in the draw file is being rendered it’s adjusting the graphics window but then fails to restore it correctly once it’s finished. So everything else drawn after that point ends up with the default graphics window.

As a workaround you might want to try writing a routine which manually walks through the objects in the draw file and renders them one by one, resetting the graphics window to the correct value after each render call. I’ve used a similar technique myself in the past (not to work around this bug, but to allow some code to look for and render specific drawfile objects which had been ‘tagged’ with text objects). For each object/group I wanted to render I think I just created a temporary drawfile on the fly and passed that to DrawFile_Render.

In terms of an actual fix, by adding a bit of debug code to the DrawFile module it shouldn’t be too hard to track down the exact object which is causing the problem. Not sure offhand when I’ll have time to look at it though.

When you want to render a section of a draw file you can call DrawFile_Render with a clipping rectangle passed in R4. We have long known that when using a clipping rectangle, DrawFile_Render identifies all the draw objects that intersect the rectangle and renders them in their entirety. Hence the clipping rectangle in R4 seems to be a device to ignore items wholly outside the area required, but to rely upon the clipping rectangle provided by the Wimp by means of a graphics viewport, which it assumes to be the context.

Using DrawFile_Render outside the desktop, where no graphics viewport is necessarily present and with just the R4 method will render (for example) complete sprites in the Draw file in their entireity except where they lie wholly outside the area required. The symptom for a draw file containing just a single sprite, part of which you want to render is that the R4 method does not work at all.

It looks like the culprit is the font cache. The PRMs don’t appear to mention it, but part of the operation of the font cache is to cache the characters as sprites. In order to initialise each sprite, the font manager redirects screen output to it (and then renders the character as a series of draw paths). This double level of sprite redirection (first in RiscOSM, and then in the font manager) is the key – your test code (and presumably RiscOSM) doesn’t create a VDU save area for the sprite, so when the font manager redirects output to its sprite the kernel throws away all the VDU state for your sprite, causing the graphics window and all the other parameters to be reset to default when the font manager finishes manipulating its sprite.

It is a bit lame that screen output redirection operates this way (there’s no way for the font manager to save your state, apart from explicitly reading & writing all known state variables), but since the system is working as designed, and there’s a simple solution to your problem (make sure you use a save area when rendering fonts into sprites), I’m marking this bug as a won’t fix. If more issues turn up in the future then perhaps we’ll revise this decision.