Le 19/01/2014 09:11, Kevin Fishburne a écrit :
> 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.
>
It's weird, as the only thing that has changed in the replacement of the
default SDL font. Up to r5936 it was a TTF font, and I replaced it by a
bitmap font I have made.
If you don't print text, how can that change the global framerate?
--
Benoît Minisini
------------------------------------------------------------------------------
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
