> On 8 Dec 2015, at 06:30, David Duncan <david.dun...@apple.com> wrote: > >> >> On Dec 6, 2015, at 4:51 AM, Roland King <r...@rols.org >> <mailto:r...@rols.org>> wrote: >> >>> >>> On 6 Dec 2015, at 20:18, Roland King <r...@rols.org <mailto:r...@rols.org>> >>> wrote: >>> >>> >>>> >>>> CALayer has a mechanism built in for the sort of thing you want to do. >>>> Read up on -[CALayer display]. You should be able to override that, or >>>> implement the corresponding delegate method in your UIView and perform >>>> management of your custom bitmap there. I myself do this in one app to >>>> share one bitmap between multiple layers for example. >>>> >>>> The other thing worth investigating perhaps is whether CATiledLayer would >>>> better suit your drawing needs, or if you could split your custom view up >>>> into a series of sub-views, so you only need invalidate slices of one or >>>> two of them. >>>> >>>> Mike. >>> >>> That’s what I was just trying. I made a subclass of CALayer() and overrode >>> just display() to do absolutely nothing at all, except print ‘display()’. I >>> then made a UIView subclass which overrides layerClass() to return the type >>> and stuck one such view randomly in my NIB. The view is made, the layer is >>> created .. and absolutely nothing else happens. I expected to get at least >>> ONE call to display() as the view/layer starts dirty, but I don’t get even >>> that. I even hooked up a button to call setNeedsDisplay on the view but >>> that didn’t prompt it either. I overrode a bunch of other methods too to >>> print but the only one which currently gets called is init(). >>> >>> I expected the UIView would drive at least an initial setNeedsDisplay on >>> the layer, and a setNeedsDisplay on the view would end up being >>> passed-through, but it doesn’t. Calling setNeedsDisplay on the actual layer >>> object itself seems to work, but I did sort of expect the UIView to do some >>> things with the layer automatically. Guess I was wrong and I will need to >>> hook all those bits up for myself. >> >> ok I begin to see how it all works now. So if the layer is the view’s layer, >> instead of a separate totally custom layer you add to the layer, then the >> view sets some things on it but not everything. It turns off >> needsDisplayOnBoundsChange (which I had set on init in the layer) unless the >> view’s contentMode is redraw, which somewhat confused me. That causes the >> layer to call display() on itself on bounds change. However it doesn’t pass >> setNeedsDisplay() and setNeedsDisplayInRect() through to the underlying >> layer which I’d have expected. I assume it only calls those that if the >> layer is a normal UIView layer and not a custom one. > > UIView will not dirty its layer if your subclass does not implement > -drawRect:. >
Ah - thanks - that’s a useful missing piece to know. I’m fairly happy now that my layer is doing what its owning UIView expects and I’m getting better performance with less CPU. Instruments has been great for this too, couple of hours looking at the heavy stack traces and watching how CPU usage changed over time, a few targetted tweaks to code I expected was going to need some kind of optimisation, I’m using about 10% of the power I was at the weekend. Good stuff. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
