Re: How to get "colored" font smoothing in a CALayer
Re: How to get "colored" font smoothing in a CALayer
- Subject: Re: How to get "colored" font smoothing in a CALayer
- From: James Bucanek <email@hidden>
- Date: Thu, 6 Jan 2011 16:04:43 -0700
Kyle Sluder <mailto:email@hidden> wrote (Thursday,
January 6, 2011 12:06 PM -0800):
On Thu, Jan 6, 2011 at 10:28 AM, James Bucanek <email@hidden> wrote:
Greetings,
The is probably more of a Carbon question than a Cocoa question, but since
the problem starts with CALayer, I'll start here first.
Welcome to the madness of CALayer. I suggest you take a very long,
hard look at whether you want to continue down this path. :) In
particular, please read my rant from last month:
http://lists.apple.com/archives/cocoa-dev/2010/Dec/msg00464.html
The summary is that Core Animation really isn't good for making
traditional UI elements. It's great for things like Front Row and
Cover Flow or as a simple scene graph API. But there's too much
impedance mismatch between AppKit and CALayer. UIKit fares better
because it was designed with CALayer in mind.
Kyle,
I agree with everything in your earlier rant, but the advantages
of Core Animation are just too much for me to pass up.
Basically, I'm working on a kind of semi-3D view of the file
system for a backup solution. As you move backwards and forwards
in time, different versions of the same document "fly" in or out
of view along a simulated Z-axis. At the same time, new and
deleted items appear and disappear, and the remaining unchanged
items smoothly rearrange themselves in the view.
After working on this code for well over a month (easily twice
as long as I expected), I agree that there is a *HUGE* impedance
mismatch between AppKet and Core Animation. But I've mostly made
it work. I now have icon (matrix), list (outline), and column
(browser) views that are completely backed by CALayers. The
basic approach is that each NS view (NSMatrix, NSOutlineView, or
NSBrowser) has a subview that hosts the CALayers. Each cell
object is just a proxy that's connected to a CALayer which
displays the cell's content. "Drawing" a cell simply updates the
state of the CALayer and prompts it to redraw.
That's the basics. The reality is a nightmare hooks and
workarounds, mostly due to the bazillion little assumptions that
the various NS view objects makes about what gets drawn, when,
and where.
Thanks for the feedback and for the tidbit on how to override
the CGContext of a CALayer. That might come in useful someday.
--
James Bucanek
_______________________________________________
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