Re: [Tuxmath-devel] Some updates

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

Hi Wenyuan,

I've now tried it on my laptop, which is 3 or 4 years old (I forget...). It's 
still about 2s on my machine, so I'm not that worried about it on machines of 
this caliber.

However, I did notice a performance problem that might be more severe: if the 
user hits F10 to toggle between full-screen and windowed modes, it takes time 
(~2s?) for the window to update. Furthermore, its substantially longer if the 
cache has not been populated at this resolution before. Interestingly, this 
only happens in the "menu" code; the game switches essentially instantly, 
presumably because that code isn't using the new loader.

Finally, as more of the graphics get moved over to SVG, I imagine that the 
delay could grow even longer. So now I'm back to thinking that perhaps your 
plan to have the graphics render in a separate thread is probably worth the 
effort.

Best,
--Tim

On Monday, July 05, 2010 10:55:25 pm Wenyuan Guo wrote:
> Hi folks,
> 
> > For a developer who might be testing tuxmath many times a day, a 2s delay
> > could become annoying. But I bet for a kid who might just launch it once
> > per day, that's probably a reasonable amount of time to devote to
> > "branding." So overall I would vote that additional optimization is not
> > necessary. Anybody feel differently?
> 
> I guess that's why I was annoyed with it at the first place, having
> sometimes to launch the program a dozen times in a short span :=). But
> it might be true that for a regular user, the 2s may not be that
> repulsive.
> 
> > Maybe we should try to test this on an old, low-powered machine to see
> > if it takes longer than 2s on such hardware.  If so, it would be
> > worthwhile to try to further optimize it.
> > 
> > As for shortening the "splash" time to less than 2s, it might be nice
> > to get it down to 1s or so, but I would consider it to be a low
> > priority.
> 
> I thought about this too. I don't have an old machine lying around
> right now. Anyone can chip in on how the program performs on their
> machines if they are relatively outdated? I suspect the main factor is
> the speed of harddisk, compound by the large number of files
> necessitating repositioning of the read head and a seek delay penalty
> for each file, compared with a large continuous file.  I think we can
> decide on whether to optimize it any further based on that.
> 
> 
> Wenyuan