Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

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

Hi Wenyuan,

On Sunday, July 18, 2010 03:11:12 am Wenyuan Guo wrote:
> Hi all,
> > As promised, I have coded a new feature that enables multithreading
> when it rescales title and menu during an in-game resolution change.
> As before, the game changes to the new resolution (either fullscreen
> or windowed) instantly. But when the user quits to the menu, it is
> usually instantaneous too, provided the worker thread has gotten
> enough time to finish (usually 2s).
> 
> However, resolution change when in-menu still inevitably takes 2s, due
> to the serial nature of the process.
> 
> The git repository has been updated. Please feel free to try it out!

I just did---it's very nice! This work is really making the graphics look far 
more professional.

I ran this with --debug-menu and did notice one oddity: if the debug output is 
to be believed, it looks like the "goldstar" and "no_goldstar" files may be 
loading once for each lesson item (i.e., a total of about 57 file-loading 
operations), rather than just once for each unique graphic (a total of 2 file-
loading operations). If this is true, it might be possible to reduce that 2s 
delay.

Also, as far as I can tell this currently applies only to the menu code. So as 
we transition to using more SVG during game play, the same delay currently 
seen only when in-menu will also appear during the game. And indeed the delay 
will increase because we are loading more files. Presumably we could first load 
the files for whatever "activity" the user is currently engaged with, allow the 
user to continue with what they were doing, and then using your nifty new 
threaded code pre-load the rest of the graphics. So the delay will not 
necessarily need to increase, but there will always be a delay.

Do you have thoughts on whether we should do something this? I see several 
options:
1. Just leave it like it is now
2. Display a message, "Changing resolution, please wait..."
3. Temporarily progress with the "current" icons, clipping or displaying 
smaller than they should be depending on whether it is an increase or decrease 
in resolution. Once the new icons are ready, start using them.
4. Call rotozoom for a quick (?) scaling, and use those until the new ones are 
ready.
5. See whether the loading time can be further reduced, perhaps by caching as 
a single big file rather than individual graphics files.
6. Use David's suggestion that we (at least optionally) always have both the 
--fullscreen and the --windowed resolution graphics available in memory. One 
thing I only just noticed is that the "--windowed" window is not resizable (I 
had been assuming it was), so that means we can rely on the size of the --
windowed graphics never changing. In our previous discussion I had been under 
the mistaken impression that this was not an option.

Best,
--Tim