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

[Wenyuan G. <guo...@gm...>]

Hi Tim,

Thanks for helping with testing and the detailed remarks!

On Sun, Jul 18, 2010 at 6:53 PM, Tim Holy <ho...@wu...> wrote:
> Hi Wenyuan,

>
> 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.

I actually observed this behavior in the earlier versions too, and not
restricted to "goldstar" and "no_goldstar" files either! Many sprites
are loaded several times for different instances of them in the menu
tree. But it should not be problem here for the latest version: hard
disk cache for modern OS is smart enough so that only the first read
of each file incurs the mechanical delay. It used to be a problem in
the earlier versions without SVG cache though, because the bottleneck
was CPU bound then, and loading and rescaling the same sprite more
than once add to that 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.

After thinking over these options for a while, I think I will give 6 a
try: in particular, we can load all cached sprites of all resolutions
at the startup, possibly in a separate thread. Later resolution
switches will not incur the hard disk delay this way. If my theory
that the current 2s is mainly hard disk bound is correct, it should
give substantial improvement for all F10 presses in-menu.

Now going back to some happy coding! I will update you once the
feature is implemented and is ready for testing.

Cheers
Wenyuan