Re: [Tuxmath-devel] Some updates

[Brendan L. <bm...@ri...>]

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