Re: [Tuxmath-devel] Some updates

[Tim H. <ho...@wu...>]

Hi Wenyuan and David,

On Wednesday, July 07, 2010 09:35:58 am David Bruce wrote:
> > Pressing F10 will require scaling of all menu sprites to the new
> > resolution. It used to take like 5s without caching. Now it roughly
> > takes 1-2s. But you have spotted a bug too! I tested the program and
> > indeed it is instantaneous when switching in-game. The reason is that
> > it doesn't scale the menu items. As a result, if you then quit the
> > game and return to the menu, all sprites will still be as big as in
> > fullscreen mode, resulted in a clipped screen. I suspect this bug was
> > present in the older versions too, i.e. before SVG caching was
> > introduced. I will look into it.

Great! I think fixing bugs is even more important than the speed optimizations 
I'll be discussing below.

> So now, if someone presses F10 when the menus are displayed, what
> happens?  Are the sprites already scaled and cached at the new
> resolution, so the program just has to read them from disk? Or do they
> have to be scaled?  If the latter, it might be a good job for a
> secondary thread to scale and cache the sprites at the "other"
> resolution (either 640x480 or fullscreen) once they have been prepared
> for the current resolution.
> We also might consider keeping both sets of sprites in memory, at
> least optionally depending on the amount of system memory.

Given that 640x480 is probably about half the # of pixels along each axis of a 
typical monitor in full-screen, they would take up only 1/4 of the memory; so 
caching both doesn't seem crazy.

That said, if the user resizes the window away from 640x480, then this becomes 
impractical as a strategy. So overall I think it's probably not worth 
it---640x480 now is just a special case and not some default we can fall back 
on.

If seeks, etc, really are the main part of the time for loading pre-rendered 
icons from disk, then perhaps we could consider writing all cached images as 
one big file. Thoughts? This would probably only worth it if it would get it 
down to a fraction of a second.

Alternatively or additionally: because the 5s black screen may be undesirable, 
what about the following as a strategy:
1. After a resize, a second thread is launched that either re-loads or re-
creates the sprites at the appropriate resolution. I think this is firmly 
within Wenyuan's current plans.
2. The existing sprites are used to immediately re-render the window (rather 
than having a black screen). As necessary, we clip images, or expand them, or 
plot them smaller than ideal, or whatever to make each fit in the desired space 
(rather than the space given the native size).
3. Once "real" sprites are available, re-render the window. For simplicity I 
would say one could just wait until they are all ready, rather than trying to 
update each one as it is prepared. So the "rescale thread," once finished, 
could notify tuxmath that a re-rendering is needed.

If it's a fair amount of code this rendering-twice approach, or if users will 
think it's a bug that the icons look so weird for a few seconds, then perhaps 
it's better to live with the delay when hitting F10. At least with caching it 
is a much shorter delay! Thanks to you, Wenyuan! And we could display a 
message on the screen: "Re-rendering images at new resolution" or something 
like that.

Best,
--Tim