lockFocusIfCanDraw behavior in layer-backed mode
lockFocusIfCanDraw behavior in layer-backed mode
- Subject: lockFocusIfCanDraw behavior in layer-backed mode
- From: Tor Arne Vestbø <email@hidden>
- Date: Sat, 15 Dec 2018 15:07:16 +0000
- Thread-topic: lockFocusIfCanDraw behavior in layer-backed mode
Hey hey,
> On 15 Dec 2018, at 01:38, Matt Jacobson <email@hidden> wrote:
>
> You were probably calling -lockFocusIfCanDraw
> <https://developer.apple.com/documentation/appkit/nsview/1483285-lockfocusifcandraw>,
> which does not say that.
Piggy-backing on this thread, what does lockFocusIfCanDraw actually do in
layer-backed mode?
Without layer-backing, lockFocusIfCanDraw could be used to draw into the
NSWindow surface outside of the normal display-cycle, in a push-fashion.
With layer-backing, it seems to set up some sort of “Null” context, and calls
setNeedsDisplay? Is the context it sets up valid and you should draw to it like
normal, and then unlockFocus And then AppKit will flush that context on the
next display cycle? Is there then a way to detect in the next display-cycle
(drawRect:/displayLayer:) that its a result of lockFocusIfCanDraw, so you don’t
actually need to redraw everything once again?
I guess this also means it’s not as synchronous as the non-layered mode where
you could use [NSWindow flushWindow] to push the result to the screen, eg:
for (int i = 0; i < animationFrames; ++i) {
lockFocusIfCanDraw
draw to NSGraphicsContext currentContext]
unlockFoucs
[NSWindow flushWindow]
}
(I know this is a bad ida, but) is there a way to achieve the same synchronous
flush with layer-backing?
Cheers,
Tor Arne
_______________________________________________
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