Re: OpenGL Vertical Syncing effect on run loops
Re: OpenGL Vertical Syncing effect on run loops
- Subject: Re: OpenGL Vertical Syncing effect on run loops
- From: Michael David Crawford <email@hidden>
- Date: Wed, 23 Sep 2015 08:37:18 -0700
My Warp Life implementation of Conway's Game of Life updates its model
- a square grid of bits - up to 8,000 times per second, but
invalidates the display with a display link. It works really well and
results in a frame rate far faster than the refresh rate but with
smooth animation.
I was puzzled that my App was getting only one-tenth of the available
CPU. This turned out to be due to my early code invalidating the
display every generation. I operated the life generation update on a
separate thread but invalidated the display on the main - GUI -
thread. Ninety percent of my CPU was devoted to back and forth
context switches that did no other work of any sort.
My current use of the display link resulted in a tenfold increase in
performance.
Michael David Crawford P.E., Consulting Process Architect
email@hidden
http://mike.soggywizard.com/
One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light.
On Tue, Sep 22, 2015 at 7:51 PM, Greg Parker <email@hidden> wrote:
>
>> On Sep 22, 2015, at 6:56 PM, Jerry Krinock <email@hidden> wrote:
>>
>> In Apple document QA1385, in Listing 2, describing how to drive OpenGL Rendering Loops 10 years ago, an NSTimer, repeating every 1 millisecond, is added to an app’s run loop [1].
>
> Just to be clear: don't do that. Use CVDisplayLink.
>
>
>> Referring to this timer, the text says that:
>>
>> "When vertical synchronization is enabled in your OpenGL application, during each retrace period, when the timer fires, …”
>>
>> Hmmmm, a timer with time interval of 1 millisecond is now going to fire during each retrace period, 16.7 milliseconds or so! This implies that when vertical synchronization is enabled in an OpenGL application, the application’s run loop, in all modes, is synchronized to the video frame and can go no faster. Is this correct?
>
> It is not. The timer would fire multiple times per retrace if it were unhindered. But at some point the timer callback will provoke an OpenGL buffer swap, and that will block until the next retrace when vertical synchronization is enabled. The gated buffer swap inside the timer callback is the rate-limiting factor, not anything in the runloop or NSTimer itself.
>
>
> --
> Greg Parker email@hidden Runtime Wrangler
>
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden