Menu
▾
▴
tuxmath-devel
|
From: Wenyuan G. <guo...@gm...> - 2010-07-18 08:11:18
|
Hi all, As promised, I have coded a new feature that enables multithreading when it rescales title and menu during an in-game resolution change. As before, the game changes to the new resolution (either fullscreen or windowed) instantly. But when the user quits to the menu, it is usually instantaneous too, provided the worker thread has gotten enough time to finish (usually 2s). However, resolution change when in-menu still inevitably takes 2s, due to the serial nature of the process. The git repository has been updated. Please feel free to try it out! Cheers Wenyuan |
|
From: Tim H. <ho...@wu...> - 2010-07-18 10:54:16
|
Hi Wenyuan, On Sunday, July 18, 2010 03:11:12 am Wenyuan Guo wrote: > Hi all, > > As promised, I have coded a new feature that enables multithreading > when it rescales title and menu during an in-game resolution change. > As before, the game changes to the new resolution (either fullscreen > or windowed) instantly. But when the user quits to the menu, it is > usually instantaneous too, provided the worker thread has gotten > enough time to finish (usually 2s). > > However, resolution change when in-menu still inevitably takes 2s, due > to the serial nature of the process. > > The git repository has been updated. Please feel free to try it out! I just did---it's very nice! This work is really making the graphics look far more professional. I ran this with --debug-menu and did notice one oddity: if the debug output is to be believed, it looks like the "goldstar" and "no_goldstar" files may be loading once for each lesson item (i.e., a total of about 57 file-loading operations), rather than just once for each unique graphic (a total of 2 file- loading operations). If this is true, it might be possible to reduce that 2s delay. Also, as far as I can tell this currently applies only to the menu code. So as we transition to using more SVG during game play, the same delay currently seen only when in-menu will also appear during the game. And indeed the delay will increase because we are loading more files. Presumably we could first load the files for whatever "activity" the user is currently engaged with, allow the user to continue with what they were doing, and then using your nifty new threaded code pre-load the rest of the graphics. So the delay will not necessarily need to increase, but there will always be a delay. Do you have thoughts on whether we should do something this? I see several options: 1. Just leave it like it is now 2. Display a message, "Changing resolution, please wait..." 3. Temporarily progress with the "current" icons, clipping or displaying smaller than they should be depending on whether it is an increase or decrease in resolution. Once the new icons are ready, start using them. 4. Call rotozoom for a quick (?) scaling, and use those until the new ones are ready. 5. See whether the loading time can be further reduced, perhaps by caching as a single big file rather than individual graphics files. 6. Use David's suggestion that we (at least optionally) always have both the --fullscreen and the --windowed resolution graphics available in memory. One thing I only just noticed is that the "--windowed" window is not resizable (I had been assuming it was), so that means we can rely on the size of the -- windowed graphics never changing. In our previous discussion I had been under the mistaken impression that this was not an option. Best, --Tim |
|
From: Wenyuan G. <guo...@gm...> - 2010-07-19 09:02:06
|
Hi Tim, Thanks for helping with testing and the detailed remarks! On Sun, Jul 18, 2010 at 6:53 PM, Tim Holy <ho...@wu...> wrote: > Hi Wenyuan, > > I ran this with --debug-menu and did notice one oddity: if the debug output is > to be believed, it looks like the "goldstar" and "no_goldstar" files may be > loading once for each lesson item (i.e., a total of about 57 file-loading > operations), rather than just once for each unique graphic (a total of 2 file- > loading operations). If this is true, it might be possible to reduce that 2s > delay. I actually observed this behavior in the earlier versions too, and not restricted to "goldstar" and "no_goldstar" files either! Many sprites are loaded several times for different instances of them in the menu tree. But it should not be problem here for the latest version: hard disk cache for modern OS is smart enough so that only the first read of each file incurs the mechanical delay. It used to be a problem in the earlier versions without SVG cache though, because the bottleneck was CPU bound then, and loading and rescaling the same sprite more than once add to that delay. > > Do you have thoughts on whether we should do something this? I see several > options: > 1. Just leave it like it is now > 2. Display a message, "Changing resolution, please wait..." > 3. Temporarily progress with the "current" icons, clipping or displaying > smaller than they should be depending on whether it is an increase or decrease > in resolution. Once the new icons are ready, start using them. > 4. Call rotozoom for a quick (?) scaling, and use those until the new ones are > ready. > 5. See whether the loading time can be further reduced, perhaps by caching as > a single big file rather than individual graphics files. > 6. Use David's suggestion that we (at least optionally) always have both the > --fullscreen and the --windowed resolution graphics available in memory. One > thing I only just noticed is that the "--windowed" window is not resizable (I > had been assuming it was), so that means we can rely on the size of the -- > windowed graphics never changing. In our previous discussion I had been under > the mistaken impression that this was not an option. After thinking over these options for a while, I think I will give 6 a try: in particular, we can load all cached sprites of all resolutions at the startup, possibly in a separate thread. Later resolution switches will not incur the hard disk delay this way. If my theory that the current 2s is mainly hard disk bound is correct, it should give substantial improvement for all F10 presses in-menu. Now going back to some happy coding! I will update you once the feature is implemented and is ready for testing. Cheers Wenyuan |
|
From: Tim H. <ho...@wu...> - 2010-07-19 12:22:18
|
Dear Wenyuan, On Monday, July 19, 2010 04:02:00 am Wenyuan Guo wrote: > But it should not be problem here for the latest version: hard > disk cache for modern OS is smart enough so that only the first read > of each file incurs the mechanical delay. It used to be a problem in > the earlier versions without SVG cache though, because the bottleneck > was CPU bound then, and loading and rescaling the same sprite more > than once add to that delay. Good point. Presumably if the cache got filled up we'd see a performance hit, but for almost any machine that can run tuxmath I doubt this will be a problem. > > 6. Use David's suggestion that we (at least optionally) always have both > > the --fullscreen and the --windowed resolution graphics available in > > memory. > After thinking over these options for a while, I think I will give 6 a > try: in particular, we can load all cached sprites of all resolutions > at the startup, possibly in a separate thread. Later resolution > switches will not incur the hard disk delay this way. If my theory > that the current 2s is mainly hard disk bound is correct, it should > give substantial improvement for all F10 presses in-menu. > > Now going back to some happy coding! I will update you once the > feature is implemented and is ready for testing. Exciting! --Tim |
|
From: Brendan L. <bm...@ri...> - 2010-07-19 19:56:17
|
Hi Wenyuan, Just updated my branch with the threading--looks nice! For the sake of portability (actually, just me and my broken Windows environment) would you mind if I changed the calls to use the SDL_Thread API instead of pthreads? AFAIK it's just a wrapper around pthreads on most environments, so the implementation/performance should be identical. Let me know if you see any problems with changing. Cheers, Brendan On Mon, Jul 19, 2010 at 7:42 AM, Tim Holy <ho...@wu...> wrote: > Dear Wenyuan, > > On Monday, July 19, 2010 04:02:00 am Wenyuan Guo wrote: > > But it should not be problem here for the latest version: hard > > disk cache for modern OS is smart enough so that only the first read > > of each file incurs the mechanical delay. It used to be a problem in > > the earlier versions without SVG cache though, because the bottleneck > > was CPU bound then, and loading and rescaling the same sprite more > > than once add to that delay. > > Good point. Presumably if the cache got filled up we'd see a performance > hit, > but for almost any machine that can run tuxmath I doubt this will be a > problem. > > > > 6. Use David's suggestion that we (at least optionally) always have > both > > > the --fullscreen and the --windowed resolution graphics available in > > > memory. > > > After thinking over these options for a while, I think I will give 6 a > > try: in particular, we can load all cached sprites of all resolutions > > at the startup, possibly in a separate thread. Later resolution > > switches will not incur the hard disk delay this way. If my theory > > that the current 2s is mainly hard disk bound is correct, it should > > give substantial improvement for all F10 presses in-menu. > > > > Now going back to some happy coding! I will update you once the > > feature is implemented and is ready for testing. > > Exciting! > > --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: Wenyuan G. <guo...@gm...> - 2010-07-19 21:40:00
|
Hi Brendan, > Just updated my branch with the threading--looks nice! For the sake of > portability (actually, just me and my broken Windows environment) would you > mind if I changed the calls to use the SDL_Thread API instead of pthreads? > AFAIK it's just a wrapper around pthreads on most environments, so the > implementation/performance should be identical. Let me know if you see any > problems with changing. Ouch! I didn't think of that issue. Thanks for pointing it out. But has SDL_Thread library got all the other pthread functions like "join"? I remember that POSIX threads are fully supported by Windows too? Have you tried to compile it under windows? Cheers Wenyuan |
|
From: Brendan L. <bm...@ri...> - 2010-07-19 22:10:21
|
Wenyuan, I'm sure SDL_thread.h doesn't expose all the functionality you can get from pthreads, but it the important stuff. Instead of a pthread_join, you'd use SDL_WaitThread, etc. > I remember that POSIX threads are fully supported by Windows too? Have > you tried to compile it under windows? I googled quickly and it looks like you're right--what a nice surprise! http://sourceware.org/pthreads-win32/ I'll try this first. -Brendan |
|
From: Wenyuan G. <guo...@gm...> - 2010-07-19 22:41:30
|
Hi Brendan, > I'm sure SDL_thread.h doesn't expose all the functionality you can get > from pthreads, but it the important stuff. Instead of a pthread_join, > you'd use SDL_WaitThread, etc. Hmm... I think in that case we might as well use SDL_threads. We can just let SDL runtime to handle cross-platform issues. My code currently only uses quite basic functionality of pthreads. Let me check what changes need to be made. Cheers Wenyuan |
|
From: David B. <dav...@gm...> - 2010-07-19 23:43:52
|
Hi Brendan, Wenyuan et al, > Hmm... I think in that case we might as well use SDL_threads. We can > just let SDL runtime to handle cross-platform issues. My code > currently only uses quite basic functionality of pthreads. Let me > check what changes need to be made. If SDL threads do what we need, we might as well just go with that. It will make our code cleaner if we can avoid a bunch of #ifdef HAVE_PTHREADS or #ifdef WIN32 conditionals to handle cross-platform differences. As it stands now, the tuxmath LAN server preferentially runs in a thread using pthreads on Linux, whereas on Windows it only works as a standalone executable (not that I've actually gotten a win32 release out with LAN support :-( ). So that ought to be converted to SDL threads as well. This may be a bit analogous to how we used SDL_net last summer instead of straight BSD sockets for the network stuff. Best, David |
|
From: Brendan L. <che...@gm...> - 2010-07-20 05:20:33
|
Hi all, > If SDL threads do what we need, we might as well just go with that. > It will make our code cleaner if we can avoid a bunch of #ifdef > HAVE_PTHREADS or #ifdef WIN32 conditionals to handle cross-platform > differences. Yep, SDL is pretty good at doing that so we don't have to :) I thought the pthreads code for the LAN game "just works" so I didn't even mention it, but so much the better if it stands to benefit as well. AFAIK it's a bit more involved than the rendering thread--are we doing anything "fancy" that might not be available from SDL? -Brendan |
|
From: David B. <dav...@gm...> - 2010-07-20 12:12:13
|
Hi, > Yep, SDL is pretty good at doing that so we don't have to :) I thought > the pthreads code for the LAN game "just works" so I didn't even > mention it, but so much the better if it stands to benefit as well. > AFAIK it's a bit more involved than the rendering thread--are we doing > anything "fancy" that might not be available from SDL? I have to look back at it, but basically I'm pretty sure I didn't do anything fancy, as it was the first and only time I have used pthreads. Initially, tuxmathserver was written solely as a standalone program. To run it in a thread, I made almost the entire contents of tuxmathserver's main() into a function called RunServer(), which could then be either called from the thread or wrapped in a minimal main() function to run on its own. This all still needs some work - one big issue is that the code isn't really thread-safe in two main ways. First, the data in mathcards.c isn't thread-safe, as the question list and related variables are limited to a single instance. Second, if the server function in the thread exits, it calls MC_EndGame(), as well as SDLNet_Quit(), which brings down tuxmath itself. If Joao Moriera had decided to work on tuxmath instead of tuxpaint, it would have been his GSoC project to straighten out these problems. Best, David |
×
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