Menu
▾
▴
tuxmath-devel
|
From: Wenyuan G. <guo...@gm...> - 2010-07-04 03:24:55
|
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 |
|
From: Tim H. <ho...@wu...> - 2010-07-05 18:58:36
|
Hi Wenyan, On Saturday, July 03, 2010 10:24:48 pm Wenyuan Guo wrote: > 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? Hmm, an interesting question. I think if we want to have the logo display for 2s, then I agree there is little point in further optimization, since you've gotten the loading time down below that. I guess the key question is whether we want to have the logo there for 2s. 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? Best, --Tim |
|
From: David B. <dav...@gm...> - 2010-07-05 19:12:10
|
Hi, > Hmm, an interesting question. I think if we want to have the logo display for > 2s, then I agree there is little point in further optimization, since you've > gotten the loading time down below that. I guess the key question is whether > we want to have the logo there for 2s. > > 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? 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. David |
|
From: Wenyuan G. <guo...@gm...> - 2010-07-06 03:55:26
|
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 |
|
From: Tim H. <ho...@wu...> - 2010-07-06 13:54:21
|
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 |
|
From: Wenyuan G. <guo...@gm...> - 2010-07-07 12:52:38
|
Hi Tim, Thanks for the input. > 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. > 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. Cheerz Wenyuan |
|
From: David B. <dav...@gm...> - 2010-07-07 14:36:05
|
Hi Wenyuan, > > 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. 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. Regards, David |
|
From: Tim H. <ho...@wu...> - 2010-07-07 16:24:11
|
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 |
|
From: Wenyuan G. <guo...@gm...> - 2010-07-08 08:25:46
|
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 > |
|
From: Brendan L. <bm...@ri...> - 2010-07-09 15:36:48
|
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 |
|
From: Wenyuan G. <guo...@gm...> - 2010-07-11 13:50:51
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X