I have many layer-backed views contained in a NSScrollview and am predominantly concerned with scrolling performance. The documentView and higher are layer-backed hence their subviews are also layer-backed.
The following are the three natural places that display/rendering code could go:
override NSView.wantsUpdateLayer to return false (or don't do anything because this is the default) & do drawing in NSView's drawRect method
override NSView.wantsUpdateLayer to return true & do drawing in NSView's updateLayer method
do NO drawing in NSView at all & perform all drawing in CALayer's drawInContext method
From the WWDC 2013 Session 215 talk it was stated that (2) is more performant than (1) because the view then doesn't need to create a temporary store for the drawRect output. Firstly, I don't have 100% clarity on when "backing stores" are made and when not and Secondly how do (2) and (3) compare and when might you use one over the other?
In particular, I have to draw text into my view. How would I go about doing that in the updateLayer call? The only examples of drawing text seem to need to get hold of a context - which isn't naturally available in updateLayer.
Related
I have two macOS apps that are very similar. One app renders an animation in 2-D, with Quartz calls, in a subclass of NSView, the other app, a 3-D animation in a subclass of SCNView (itself a subclass of NSView) using SceneKit geometries. In each case the "view" is owned by a view controller and that ownership is set in a storyboard. In each case I use a timer to dirty the view every second so its drawRect gets triggered to drive the animated movements. In each case I have used: self.view.needsDisplay = true
In the 2-D case, drawRect is called in the view instance, in the 3-D case it is not (even for the initial render).
I'm puzzled! Does SCNView suppress calls to drawRect? If so, how might I get around this? If not, what voodoo secret have I missed?
If this behavior is not what readers would expect, I will post a sample project which exhibits it.
I know that SceneKit can take advantage of Core Animation but I want to keep the same general timer mechanism in both apps because the animated content is, essentially, the same action, what was flat in 2-D is spherical in 3-D so using SceneKit rendering made sense.
Added an Xcode project to show different NSView and SCNView behaviors:
https://www.dropbox.com/s/qtymzitkqcqhfje/SCN.zip?dl=0
You're fighting the framework.
SceneKit has its own timers for rendering and animation. Hook into those to update your objects' properties (locations, colors, etc). Let SceneKit handle the draw calls.
The methods you need may be in unexpected places. Take a look at documentation for SCNSceneRenderer and SCNSceneRendererDelegate protocols. The renderer delegate documentation explains the render loop and shows you where to customize your app's animations and physics.
I have an application I'm writing in which I'm drawing into an NSView. In mouseDown I am saving the location in my data model and then drawing a graphic at that location within the drawRect method of the view. It all works fine.
At the end of my mouseDown I was calling [self setNeedsDisplay:YES]; to force a redraw. The only thing is that the dirtyRect is always the full size of the view. I wanted to optimize this as much as possible so that I'm not redrawing the entire window for just a few changed pixels.
So now I'm calling [self drawRect:...] instead and specifying the rectangle.
Now in my drawRect I am comparing every graphic I have to see if it falls in the dirtyRect. It seems like I've traded work of drawing for work of bounds checking everything. I'm not sure I've made it any more or less efficient.
So what is the standard practice? Is it common to just redraw everything in the view and ignore the dirtyRect? Is there a nice function I can use as a test to see whether my object is in the dirtyRect?
You should never call -drawRect: yourself if you're trying to draw to the screen. Let AppKit call it for you. What you should do is call -setNeedsDisplayInRect: at the end of your -mouseDown:.
Then, in -drawRect:, only draw stuff contained in the dirtyRect. You can test to see if a point is inside the dirtyRect with NSPointInRect(). There are lots of other useful functions for working with NSRect. See the documentation for the point functions and the rectangle functions.
I have an application with an NSTableView in a window. I want to use a CALayer as the background for the entire window, and the table view. In all my my experiments so far, the CALayer always draws over the NSTableView, which is not the effect I'm looking for. Is there a way to make this work, or am I simply out of luck due to the nature of layer-hosting views vs NSViews?
My test setup is a window with the usual NSScrollView/NSTableView combo, and a sibling NSView behind it in the view order. The NSView is set to be layer-hosting with my custom layer within it (just a layer with a backgroundColor set). I've experimented with setting the window's content view to be layer-backed, as well as the table view itself, as well as wrapping the NSScrollView in a layer-backed NSView. The result is always the same.
Thanks for any insight you might be able to provide.
It is simple. all overlapping views or layers should be layer backing or layer hosting for correct ordering.
you can set [tableview setWantsLayer:YES]
or simply check it in the layers tab when editing the interface.
I'm having a problem since Lion introduced elastic scrolling (pictured below). When you scroll my table view (cell-based, with alternating row colors) beyond its bounds, the background doesn't draw. I've tried doing my own drawing in -[drawBackgroundInClipRect:], but it seems like you can't exceed the bounds of the table view. How can I extend the background into elastic scrolling territory?
In Answer to Your Question
A view drawing outside its bounds is generally a no-no. When using alternating background colors, the NSTableView draws its background directly. But in a view-based table view, NSTableRowView is used and if it has its own background color, this is poses even more challenge.
The Bad News
The assemblage of NSScrollView (and its various parts), NSTableView, and NSTableHeaderView is complicated on its own. Once you throw view-based functionality into the mix (where each row has a view and each cell has their own view, and each are reused, animated around, etc.), overriding this behavior "is no way to go through life, son!" ;-)
The Good News
The issue of alternating background colors not extending in an elastically-stretched scrolled table view has been resolved (at least on 10.10, that I can tell), so this is no longer an issue unless you have row/cell views with custom backgrounds or just background colors.
A General Solution For Custom Document (Scrolled) Views
For all other scrolled views with ruled backgrounds you wish to extend for elastic scrolling, you'll need a custom NSScrollView subclass that expects a document view (your custom scrolled view) to conform to a protocol you define (like -(NSImage *)backgroundImageForClipViewBounds:). The scroll view would observe its content view (NSClipView) for bounds change notifications and flag itself for display. When the scroll view's -drawRect: is called, it would then ask the scrolled view for its -backgroundImageForClipViewBounds: (via your protocol) and draw it into itself, thereby making the scrolled view's "infinite background" its own.
I haven't tested this theory but I believe it would work. I hope this helps.
i have a CALayer with a custom draw method I've added to my view's base layer. I set needsDisplayOnBoundsChange to NO. However, when I resize the parent view's frame, the layer's drawInContext: is getting called continuously. I'd like the contents to scale while the resize is occurring. Any clues?
Interesting, I have a case where I have a CALayer that correctly scales its contents until I call setNeedsDisplay on it to redraw its contents. One thing that may be different is that in my case the layer is being drawn by its delegate and not by a subclass of CALayer. Another thing that may be different is that this is on iOS and not OSX (I don't know which you are using in this case). It is possible that there could be behavior differences between subclasses and delegate drawn layers and/or iOS and OSX.
Another thing to note is that needsDisplayOnBoundsChange is documented to be NO by default, so one should not need to set it. I am not specifically setting needsDisplayOnBoundsChange on my layer.
You could try using a delegate to do the drawing to see if that makes a difference. Note that a UIView cannot be a delegate to a CALayer. In my case I made a simple delegate object that forwards the draw call to my view.