On May 12, 2005, at 6:08 PM, Steve Mills wrote:
>What I'm toying with is changing the gworlds to CGImageRefs or CGBitmapContextRefs. (I currently can't figure that out, because one of the docs says you can draw a CGBitmapContextRef with CGContextDrawImage, but that just crashes required a cast too).) Can anyone tell me if it would be faster to draw all the background stuff (gray gradient, ticks, labels) straight to the window context every time, or would caching it in some type of Quartz "offscreen" and drawing that to the window context be faster? Keep in mind that each ruler can show a few hundred ticks and a couple dozen text labels when zoomed way out, so that's a lot of calls to draw each line as a path and each label via HIThemeDrawTextBox.
In case this helps:
1. With Quartz, you "draw into" 1 of 2 things: either:
a) CGContextRef
this is like a window, or a PDF document, or similar.
I think of it as a window.
b) CGBitmapContextRef
this is like a gworld. a bitmap buffer.
2. In QD, you could "jump" between a window and a gworld
using CopyBits. Draw to the screen directly, and the CopyBits
the bitmap over to a Gworld, or vice versa (usually vice versa, but
not always).
In Quartz, no more CopyBits, so you have to think ahead. If you are
every going to want those bits for anything, you had better write
them into a CGBitmapContextRef first. Once you draw to a CGContextRef
(i.e. a window), it's gone.
You can "CopyBits" in one direction: CGBitmapContextRef --> CGContextRef.
Here is the outline of the code, with gworld stuff (as I think about it) in [ ].
a) CGBitmapContextCreate [ make the gworld ]
b) Do your drawing into that CGBitmapContextRef [ set the port to the gworld ]
c) When you're ready to put that into a window (CGContextRef),
get the "bits" in the CGBitmapContextRef via:
provider = CGDataProviderCreateWithData(***, CGBitmapContextGetData( fromCGContext ), *****);
d) Then make a CGImage using this provider
regImage = CGImageCreate(****, provider, ******);
e) Then draw this CGImageRef into your window (CGContextRef)
CGContextDrawImage(myWindowCGRef, regImage);
[ (c)-(e) = CopyBits(gworld --> window), CG style ]
(note: you can draw into a CGContextRef until you run out of electrons, but
you won't see anything with your eyes until you do a CGContextFlush (unless you're
playing with compositing windows and such)).
3. Some Quartz drawing commands are deadly on speed. Unless you're printing
(or making a PDF), never stroke a path when you can just fill it. StrokePath does all
kinds of intersection tests on the path so the PDF stuff comes out perfect; but for
screen drawing and refreshing on anything complicated, it will bring your app
to its knees. Figure out the "bounding path" for a given path, and fill it. Silly,
I know it sounds, but ...
Similarly, cacheing to a CGBitmapContextRef (and either saving the CGBitmapContextRef
or the CGImageRef you make from it) is essential
for speed - if you needed to do this in QD for your app, you probably need to do the same in Quartz.
Probably keeping a "core" template image in a CGBitmapContextRef, and then duplicating and
then drawing into this duped CGBitmapContextRef any new tick marks etc. needed for a refresh
would be the way to go.
-Robert
--
Robert R. Curtis, Ph.D.
Managing Partner
MathMonkeys, LLC
Producers of LiveMath Software
26 Church Street, Suite 300
Harvard Square
Cambridge, MA 02138 USA
617.497.2096
617.497.2116 FAX
email@hidden
http://www.livemath.com
AOL IM: LiveMath
ICQ: 258662981
Yahoo IM: LiveMathRobert2004
_______________________________________________
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
This email sent to email@hidden
