[Gambas-user] sdl Draw event overhead is killing frame rate

[Benoît Minisini]

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