[Tuxmath-devel] Some updates

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

Hi all,

Firstly a quick bug fix report: While I was playing around with the
program, I found a bug that causes tuxmath to crash (segfault) if the
user clicks on the STOP button when picking a lesson for hosting a LAN
game. The program didn't expect this behavior and would still try to
print out the returned lesson string and crash. Now it will simply
cancel the LAN game hosting attempt and return to the upper level
menu.

I've been profiling the game to accelerate the startup sequence
further, since the last update with SVG caches. In particular, I
wanted to hide the remaining menu loading latency in a worker thread
that runs parallel to the starting title animation (when "tux of math
command" slides nicely across the screen). This turns out to be
impossible/unnecessary after a closer examination of "titlescreen.c".
Basically, there is a section of startup code there that locks us for
at least 2 seconds at the logo screen, polling ESC press from the
user. Presumably the program gives the user a grace period should he
want to quit. In addition, my profiling suggests that the total time
for menu loading and other initializations, after the last caching
optimization, only takes 1.4 seconds (on my machine). That is to say
that this latency is entirely hidden within the compulsory wait period
already. As long as we do not change that section of code, there is no
more acceleration possible for the startup sequence (that is, 2
seconds at minimum).

My question is what is your experience with the current startup
process of tuxmath. I know the performance and experience may differ
from one machine to another. Or perhaps we can eliminate that
compulsory ESC polling period and do multithreading for menu loading
in favor of faster startup?  Or maybe there is no more need for
further optimization and I should move on to the next phase of the
project? What is your opinion?

Cheers
Wenyuan