Re: [Tuxmath-devel] Some updates

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

Hi Brendan,

Thanks for the detailed remarks! What you have said about 1-5 are
correct and is exactly what is happening within the latest code.

The "rendering thread" we've been talking about are not relevant to 2
and 4. It is pertaining to 5 only. The purpose of that thread is for
the program to reload all the menu sprites already cached as PNG
concurrently while the user continues to play the game after pressing
F10. We also discussed a bit about multithreading for startup, i.e.
step 3. But our experiments showed that it is not really helpful, as
currently the program locks the user at startup for a minimum of 2s no
matter what, which is shorter or comparable to the time needed to do
the loading of cached PNG sprites.

As far as I know, game sprites are loaded in the same manner as menu
ones. Because the caching mechanism is implemented in the common
loading functions, it should apply to both types.

Cheerz
Wenyuan

On Fri, Jul 9, 2010 at 11:36 PM, Brendan Luchen <bm...@ri...> wrote:
> Hi all,
> Two small remarks. FWIW, with the latest code, I get a ~5-second delay on my
> somewhat-dated laptop when starting the game, and when switching
> resolutions. Second, if a "rendering thread" is an option, why not simply
> invoke it immediately when the game runs? The menu runs responsively in the
> first place, and everything is prepared for future resolution switches.
> I've been just skimming the conversation (been away for the past week) but
> things sound like they're getting complicated. As I understand it, things
> currently work like this:
> 1. TuxMath is distributed with SVG "source" images*
> 2. When first run, the SVGs are loaded, scaled, cached and saved as PNG at
> the user's custom resolution.
> 3. On future runs, the PNG images are found and can be loaded directly.
> 4. The first time resolution is changed to something else**, we again have
> to load, scale, cache and save the images from scratch
> 5. If both "sets" of user-tailored images are available, resolution can
> switch on the fly by loading PNGs from disk
> *This is a naive assumption, since IIRC lots of PNG art still hasn't been
> replaced.
> **Presumably this is because you hit F10, but could also come about from a
> system resolution change.
> I think 2 and 4 both take the same amount of time (~5s) but only need to be
> done once each. 3 and 5 take a palatable ~2s, with the important difference
> that 3 is done on startup, which is fine, but 5 is done in-game, and should
> be immediate from the user's point of view.
> Did I miss anything? And maybe this is a stupid question, but are menu
> sprites handled differently somehow from gameplay sprites?
> Best,
> Brendan