Re: Layer hosting views, geometryFlipped, and subviews
Re: Layer hosting views, geometryFlipped, and subviews
- Subject: Re: Layer hosting views, geometryFlipped, and subviews
- From: Kyle Sluder <email@hidden>
- Date: Thu, 16 Dec 2010 11:09:53 -0800
On Wed, Dec 15, 2010 at 11:53 PM, Gideon King <email@hidden> wrote:
> Hi, I have a layer *hosting* view which has to use the geometryFlipped option so that it behaves correctly, and need to add an NSTextView subview for editing sometimes, and an ordinary custom view for editing at other times.
Ohhh, boy. :)
After a year and a half, many Radars, and at least one DTS incident
all spent dealing with layer-backed and layer-hosting views, I can
only make the professional recommendation that you avoid using Core
Animation for anything other than a convenient OpenGL scene graph
management API. Core Animation's interaction with AppKit is simply
broken. This is not to besmirch the hard work of David Duncan, et al.,
since this is a really hard problem. But at this point, I would be
equally happy with either of the following scenarios:
1. Apple fixes layer-backed and layer-hosting views and rewrites *all*
of AppKit with Core Animation to show that it can work. That means
replacing NSCells with CALayers and otherwise factoring their drawing
along the lines that a Core Animation user (or iOS developer) would
expect.
2. Apple narrows Core Animation's scope to high-performance 2D and
pseudo-3D OpenGL scene graph management, and removes layer backing
from the API entirely. Perhaps, instead, they could focus their 2D
acceleration back on QuartzGL.
> I am having trouble working out where to place the subview. It just seems to end up in strange places.
You really don't have a layer-backed view. You have a layer-hosting
view, which is what you need if you want to play around with its
layers. Adding subviews to layer-hosting views is not supported
(there's a bunch of voodoo going on behind the scenes to support naïve
use of Quartz in a layer-backed context). David's suggestion to you
was the same advice given to us: create a layer-backed peer view to
your layer-hosting view in which to host your field editor and other
ancillary views.
> I have noticed also that the subview is drawing with reversed flippedness. I am wondering if there is some workaround for this by either putting another layer or view in between my layer and the overlay view? I have tried some options but so far without success.
Flippedness is broken. rdar://problem/8009542
That is a categorical, unequivocal statement of fact. The layer
machinery cannot deal with views that return YES from -isFlipped. If
you follow David's advice, you will find that your view will scroll in
the opposite direction as intended, and will snap to bizarre sizes
when the scroll view is resized.
The only way I have found to fix that is to swizzle NSClipView's
implementation of certain methods to call private LayerKitGlue API.
Before the announcement of the App Store, this only worried me because
it might go away or otherwise break despite our best efforts to guard
against it. But now we're threatened with rejection for violating the
terms of the Mac App Store.
You will also need to deal with other undocumented behavior that
LayerKitGlue relies upon to do its job. For example, your override of
-resizeWithOldSuperviewSize: *must* call super's implementation, even
if you specifically want to avoid super's effects.
rdar://problem/8659667 Otherwise, you will get video garbage if you
live-resize a view.
Once you've got the layer geometry kinks worked out, there are some
issues with drawing layer contents. For example, NSLayoutManager
spellchecking is entirely broken. rdar://problem/8644121 It seems to
suffer similar confusion about flippedness; it draws the underlines as
if the graphics context is not flipped. It doesn't go through the
public -drawUnderlineForGlyphRange:… API to draw the red-dotted
underlines; there's a separate private API it uses (possibly to
facilitate background thread spell checking, though we have disabled
that).
That's assuming you're able to recite the magic incantation to get
subpixel antialiased text in the first place. For obvious reasons,
subpixel antialiasing requires opaque contents in the backing store in
order to do its job correctly. But merely filling your backing store
before drawing your text is not enough; you must create your own
CGBitmapContext with
kCGImageAlphaPremultipliedFirst|kCGBitmapByteOrder32Host in which to
do your drawing. There is no documentation indicating that this
combination of flags is required for subpixel antialiased text.
And when I say "merely filling your backing store," that of course
implies that you will mimic Core Animation's render process in order
to precompose the underlying layers into your opaque text-carrying
layers' backing stores, thus negating much of the benefit of using
Core Animation in the first place. And you will need to go through
great pains to match color spaces, or else your precomposed version of
colors will differ slightly but noticeably from that used by Core
Animation. There's no documentation about what color space Core
Animation operates in, but I think we've worked it out to be the same
as the window's color space. Regardless, we still have one
least-significant-bit of error between our drawing and Core
Animation's drawing. I imagine this error is unrecoverable.
Once you've finally got your view nice and pretty, do you plan on
printing it? If so, you're back in Quartz land anyway, unless you want
to blat a 72dpi bitmap to the printer. Which you don't. :)
> I see that a previous question along very similar lines was asked by Kyle Sluder, but there didn't appear to be any replies to his question.
:)
> Any suggestions would be most welcome.
My professional suggestion: avoid using Core Animation for anything
related to traditional UI. CA is great for things like Front Row,
sprite-based animation/games, overlays atop Core Video movie playback,
data visualization (but be careful here! sometimes it's also the wrong
tool for building data visualization)... it's not good for writing the
next version of your productivity app's main content view.
--Kyle Sluder
_______________________________________________
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