← Back to team overview

kicad-developers team mailing list archive

Re: [PATCH] No GAL FPS Limiting for OS X

 

Any other OSX devs object to this being committed?  Also, do we really
need to throttle on the other platforms?  If not, I would rather not
have the ugly platform specific #ifdef/#endif code if we don't need it.

On 2/6/2016 10:25 AM, Bernhard Stegmaier wrote:
> Hi,
> 
> attached a patch to disable the below mentioned FPS limitation on OS X.
> 
> Without limitation/timer scrolling is smooth as expected.
> Even with heaviest scrolling or other use-cases I tested I did not
> observe any increased CPU load.
> 
> At least, from a user perspective possibly drawing too often seems way
> better than having nasty hangs due to the excessive timer latency.
> 
> 
> Regards,
> Bernhard
> 
> 
> 
> 
>> On 31.01.2016, at 16:45, Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx
>> <mailto:stegmaier@xxxxxxxxxxxxx>> wrote:
>>
>> Hi all,
>>
>> I was looking why panning in GAL canvas on OS X is sometimes very jerky.
>>
>> I found out that GAL implements a framerate limiting using a timer,
>> which blocks further updates if you try to refresh with >60Hz.
>> With a Mac touchpad you easily get scroll events >60Hz, so that hits
>> quite often.
>>
>> Problem is, that the timer event to unblock again at least on my
>> MacBook often needs between 200ms and 500ms instead of the max. 17ms
>> it should have. If this happens, you get “hangs” while panning.
>>
>> I tried to throttle mouse events to <60Hz to avoid hitting the timer.
>> Unfortunately, this doesn’t seem to be enough, because
>> EDA_DRAW_PANEL_GAL::Refresh still seems to be called very frequently
>> (<<17ms, often with a delta of 0ms or 1ms). So, timer still kicks in
>> and blocks things more than needed.
>> I also did notice that EDA_DRAW_PANEL_GAL::Refresh is called on every
>> mouse move (with default system mouse cursor)… is that also intended?
>> For updating status bar?
>>
>> Any ideas on either how to improve the timer or how not to make it
>> kick in?
>>
>> I already did try to use the wxTimer::Notify() function instead of
>> having a wxTimerEvent delivered, but that didn’t make any big difference.
>> I didn’t investigate the timer implementation of wxWidgets on OS X,
>> maybe the latency already is there before any wxWidget event handling.
>>
>> Or, wouldn’t it be more appropriate to use something like the vertical
>> sync 
>>   https://www.opengl.org/wiki/Swap_Interval
>> to limit drawing instead of this timer?
>>
>>
>> Regards,
>> Bernhard
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 



Follow ups

References