On May 31, 2006, at 12:55 PM, Olaf Krzikalla wrote:
1. Due to the above approach there is a conceptional flaw in my
software architecture (lets say, it's not as simple as it could
be). Actually, I want to cache an image in a CGLayer immediately
after I've loaded or created it. But I had to introduce some sort
of an 'inbetween-structure' to transfer the creation of the CGLayer
to the draw event handling.
2. The performance of the draw event handling becomes
unpredictable. Creating a CGLayer with some content is a rather
costly operation (compared to copying the layer to a CGContext),
which I better should make outside the draw event (nobody bothers,
if some animation stops during some loading process or the like,
but everybody does (including me) if it occassionally happens
somewhen else).
I could be wrong, but I think the context you use to create the layer
is only used to determine things like the type of context (e.g.,
bitmap vs. PDF), pixel depth (for bitmaps), and color space.
Otherwise a CGLayer isn't really very useful for its main purpose of
caching drawing operations, because you never know if you're going to
get the same context twice as part of drawing events. I think it's
safe to use any context from the window where you intend to draw,
although this may change during the life of the window if the user
changes the depth of the screen or moves the window to another screen.
Having said that, I don't think there's any way to get a context for
a Carbon window without using QuickDraw (specifically
CreateCGContextForPort), so the solution will depend on your
willingness to use a deprecated function. If it were me, I wouldn't
worry about this function becoming obsolete in the foreseeable future.
Nick
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Quartz-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/quartz-dev/email@hidden
