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

[Kevin Fishburne]

On 01/19/2014 10:36 AM, Benoît Minisini wrote:
> 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?
>

It must provoke some acid reflux deep within the bowels of SDL. :) I 
don't know...it's damn strange for sure. I also find it strange that the 
FPS is around 500, but when you minimize the window it jumps to over 
2000. Even if it's just refreshing the window itself, you'd think on a 
modern system with hardware acceleration it would be faster than that.

I attached my test app. It has all the OpenGL commands and variable 
declarations commented out, so it's running just an empty SDL loop with 
the frame rate calculation and console printout. Feel free to test the 
two revisions yourself to see the difference.

Just thought of something...how can you change the current font SDL is 
using? I wonder if changing it from the bitmap to an arbitrary TTF (even 
though no text is being rendered) would make a difference?

-- 
Kevin Fishburne
Eight Virtues
www: http://sales.eightvirtues.com
e-mail: sales at ...1887...
phone: (770) 853-6271

-------------- next part --------------
A non-text attachment was scrubbed...
Name: SDL_Draw_Event_Test.tar.gz
Type: application/gzip
Size: 40723 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20140119/5e63a65a/attachment.gz>