Re: [Tuxmath-devel] Some updates

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

Hi Tim,

I just fixed the bug that caused clipped screen, if the user switches
to windowed mode in-game, and then return to the menu. The cause was
that the program did not re-render title background and menu items
unless the resolution switch happens at the menu itself. The behavior
is correct now.

Specifically, menu re-rendering is not invoked immediately so as not
to break the flow of the game (that is, the switch is instantaneous
in-game as before). It happens only when the user finishes/aborts the
game and is about to return to the menu. This, of course, gives a 2s
delay even with SVG caching. But I think your suggestion is very good:
we can use a second worker thread to do the menu rendering while the
user is still playing the game after the switch; by the time he quits
the game, the menu would be ready and there's no delay. This of course
doesn't apply to the case where the resolution switch happens at the
menu itself, because multithreading or not, we just have to wait for
menu sprites to be ready. I will implement this feature as the next
step.

cheerz
Wenyuan

On Thu, Jul 8, 2010 at 12:24 AM, Tim Holy <ho...@wu...> wrote:
> 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
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>