From what I can tell however, that requires you to obliterate what
is in the destination to specify the alpha. Whereas with Quartz you
can specify the alpha directly (albeit not per-component).
Where weigth is the appropriate component of the OPColor.
If OpColor.red=green=blue this is essentially what Quartz alpha
drawing is about. Why not?!
I hadn't seen the OpColor field (was looking in the [C]GrafPort
declaration instead of the GrafVars decleration -- been a LONG time
since Quickdraw for me =p).
Of course, unless you need to communicate with HIToolbox, your
welcome to use CGPathRefs for your clipping needs :).
Who said "clipping"?! :)
I know, reporting areas is at issue... I just wanted to sidestep it
since it isn't really a CG issue :).
I mean it is hard (if possible at all) to try to mimic QuickDraw
drawing command sequence with Quartz: QuickDraw sequence could set
clipping to what it like at will, interleaving it with setting other
context attributes. In Quartz you can only "subtract" from clipping,
if you want to go to "larger" unclipped area you'll have to restore
context from the saved stack, and doing so will restore (ruin) other
information as well. Besides, as there are no (or few) accessors
for most of the info in context, you can't just grab the info from
context, restore state (to reset clipping to some other area) and
reapply info to context - no accessors. Hmm, I'm not sure I speak
clear enough this time of day, am I?
I think this is really just a case of "You can't directly port
Quickdraw drawing to Quartz". You can't do the same order of
operations in Quartz as you did in Quickdraw in many cases, but the
end result, the image you get on the screen, should be reproducible.
It's simply not a matter of "change all my FillRect() calls to
CGContextFillRect()".
Err... I mean the "ref" that is format agnostic (pdf, tif, jpg, etc...
So, e.g. I can write: ref = XXXNewRefFromFile without caring about
what particular format the file is and then XXXRefDraw(ref).
For all those formats (except PDF since it's a vector format) you can
use Image I/O. CGImageSourceCreate*() and
CGImageSourceCreateImageAtIndex() will get you a CGImageRef from
files that are in most popular formats. You have to go in a different
direction for PDF, but it's one of those things that isn't
terrifically difficult, even if it's somewhat inconvenient.
No drawing procs, sorry :).
... plus drawing proc :)
ref = XXXNewRefFromDrawingProc(proc, userData);
Actually to some degree you can mimic this with a CGDataProvider. The
data for it can come from anywhere, and you get a callback to supply
it. However, you can get very weird results if you don't supply the
same exact data every-time in certain situations, so it isn't a
general way of sending arbitrary data on demand. Basically, you
should consider a CGDataProvider as "1 result per provider".
If you need to interface with the toolbox,
Who doesn't? :)
You'd be amazed how many people don't. They just generally aren't on
this list.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
