On 01/17/2014 11:00 PM, Kevin Fishburne wrote: > On 01/16/2014 05:07 PM, Benoît Minisini wrote: >> Le 16/01/2014 22:40, Benoît Minisini a écrit : >>> Le 16/01/2014 06:03, Kevin Fishburne a écrit : >>>> The results are in, and they don't tell me much. :( I attached the >>>> updated test project, which includes the test results in comments at the >>>> top. They are: >>>> >>>> ' No Stop Event | No Geometry | Binary NVIDIA driver | 236 FPS >>>> ' Stop Event | No Geometry | Binary NVIDIA driver | 158 FPS >>>> ' No Stop Event | No Geometry | Nouveau driver | 238 FPS >>>> ' Stop Event | No Geometry | Nouveau driver | 159 FPS >>>> ' No Stop Event | Geometry | Binary NVIDIA driver | 236 FPS >>>> ' Stop Event | Geometry | Binary NVIDIA driver | 155 FPS >>>> ' No Stop Event | Geometry | Nouveau driver | 218 FPS >>>> ' Stop Event | Geometry | Nouveau driver | 161 FPS >>>> >>>> Adding "Stop Event" reduces thread CPU usage from 100% to 84%. The frame >>>> rate is consistently lower when using Stop Event. That 16% difference in >>>> CPU also doesn't seem to correlate with the difference in frame rates, >>>> as the frame rate difference has a significantly larger discrepancy. >>>> Factors unknown to me could be contributing to that of course... >>> It's actually simple: when 'Stop Event' is used, the process is paused >>> during a little delay (about 10 ms according to the SDL_Delay function >>> documentation). So it acts as a frame rate limitation. >>> >>> If you don't use 'Stop Event', there is no such delay. But you get in >>> both cases a call to the Gambas event loop with a 10 ms timeout (yes, 10 >>> ms again. This is usually the smallest delay a Linux Kernel can handle). >>> That means if there is no Gambas event to process, the process is paused >>> during 10 ms. If there is a Gambas event to process, there is no pause. >>> >>> I will try to remove all this delays, and you will tell me if it helps you. >>> >> Please test revision #6085, and tell me if it changes anything in your >> framerate. >> >> I removed the delay if Stop Event is called, and I lower the timeout of >> the Gambas event loop call to 1 ms instead of 10 ms, which force Gambas >> to use a busy loop instead of sleeping the process. >> > The FPS are the same when not calling Stop Event, but are now faster > when calling Stop Event. Either way they still max out between 230-240 FPS. > > I set up a VM so I can compile specific revisions of Gambas and will see > if older versions exhibit different behavior. I'll let you know what I > find, and hopefully will be able to narrow it down to a specific > revision. If I can't do anything to get a higher frame rate on an empty > SDL loop then something's gone horribly wrong on my end. > Here are the results of my test ("---" means similar to the results below):
-=- Revision Version Status FPS FPS 1280x720 Minimized 5938 3.5.90 Bad --- --- 5937 3.5.90 Bad 160 187 5936 3.5.90 Good --- --- 5931 3.5 Good --- --- 5923 3.5 Good --- --- 5907 3.5 Good --- --- 5875 3.5 Good 530 2595 5750 3.4.90 Good 490 2405 5500 3.4 Good 488 2545 -=- It seems the change slowing the SDL Draw event (or whatever is happening) appeared in revision 5937 and later, with the change absent in 5936 and earlier. What's interesting is that the SDL window being minimized in 5936 or earlier greatly increases the frame rate, though it makes no difference in later revisions. Regardless, the FPS in 5936 and earlier are significantly higher than those of revisions 5937 and newer with both empty and populated Draw event procedures. That would effect any program using SDL to create/manage a window. -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sa...@eightvirtues.com phone: (770) 853-6271 ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user