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

[Kevin Fishburne]

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: sales at ...1887...
phone: (770) 853-6271