Re: Quickest Drawing Method
Re: Quickest Drawing Method
- Subject: Re: Quickest Drawing Method
- From: Uli Kusterer <email@hidden>
- Date: Sun, 22 Jul 2007 15:50:09 +0200
On 22.07.2007, at 14:18, spiderlama wrote:
- stretching a couple of images to size and drawing them
Can you do this beforehand, perhaps? Or composite the images into
each other, and thus only scale the final image once? There are
numerous ways to optimize stuff like that in general. Are you
cacheing your images, or recreating each time? And what are you
actually using this for? Animations? A status display? Graphing? What?
- applying a mask image (I think using a NSBezierPath to make the
mask image would be quicker than using a black and transparent PNG
file).
You'd have to profile that. Are you using CoreGraphics for the mask
image? CG has built-in masking, but last I checked this wasn't
exposed through NSImage or NSGraphicsContext. Also, it helps if you
only copy and redraw those rects that actually need to be drawn. E.g.
not drawing something is always faster than clipping it out.
And again, depending on what gets masked and what's doesn't you
could probably improve performance a lot by only applying the mask on
those parts that actually need it. It also depends on what commands
you actually use to apply the mask. Can you maybe just draw using an
alpha channel from the start instead of masking?
This all happens when I call setFrame for the custom window. Is
OpenGL still viable for an odd-shaped image (not rectangular; with
transparencies)? Or by using Quartz and CG* functions is that the
same as OpenGL?
I think you'd have to do a lot of the initial drawing and masking
in Quartz, (CG or NSImage), but yes, OpenGL supports transparency and
compositing, so it'd be easy to do the scaling and drawing on top of
each other in OpenGL.
Yeah I checked it out. There's a window for each icon plus more!
Crazy.
AFAIK each window is essentially backed by an OpenGL quad, at least
when running Quartz Etreme. That's why you can drag them so quickly,
and why drawing into one window behind another (and even into
transparent windows) is fairly fast.
Right now I have a "scheduledTimerWithTimeInterval:0.1" that calls
a function that just updates the custom window's size;
What?! Why? What for? Unless you're doing animation, you shouldn't
need to use a timer to react to resizing. There are messages and
notifications sent whenever a window moves or resizes, or you can
make one window a subwindow of another to have them move together.
Those will generally cause your view's drawRect: method to be called
the next time it's needed (and whether it's needed is determined by
calls to setNeedsDisplay:, or even better setNeedsDisplayInRect:.
this is quite draining on the resources as well as jumpy. What can
I do to get this resize function called a lot, but without killing
the system? Maybe a run loop callback?
What are you actually trying to do? So far, this sounds like you're
going about things all wrong, and that's why you're getting bad
performance.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
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