Re: Quartz/memory benchmarks...
Re: Quartz/memory benchmarks...
- Subject: Re: Quartz/memory benchmarks...
- From: Brent Gulanowski <email@hidden>
- Date: Thu, 27 Jun 2002 20:09:33 -0400
On Thursday, June 27, 2002, at 01:24 AM, Charles Jolley wrote:
After some experimentation I discovered that displaying an NSImage was
apparently well optimized in 10.1, so I set about trying to find a way to
draw these complex subviews into an offscreen image and then to
substitute the offscreen image for actual drawing during key times. This
turned out to be an incredibly difficult process because Cocoa provides
no easy way to obtain an image of a view and its subviews if that view is
not entirely on screen. I even used a technical support incident for
this, though even Apple DTS was not able to give me a very good solution.
(Although they did try, I'm not trying to criticize them.)
This is what I was thinking would be the optimal road. Drawing into an
active view always seems to have pitfalls, especially if you keep
redrawing. I would be looking for a way to draw (that is, call Quartz
drawing routines) only when the actual data changes; otherwise, copy from
offscreen. No wonder people are still sticking to QuickDraw for Carbon
games!
A roadblock seems to be that you can't use NSViews inside of an NSImage.
You basically have to fake it. But isn't that expected when you're looking
for performance? I wish I knew more, but it sounds like the problem is due
to an attempt to continue to use the AppKit view hierarchy while wishing
for accelerated drawing. I've re-read the messages and I don't think
anyone has addressed this.
I admit I'm new to this stuff myself, but I'd like to see the sample
application, Allan, and look at the design and see what can be
reconsidered. Does your custom view have sub-views? How are you drawing?
What are you drawing? Many scroll views in existing AppKit classes seem
pretty darn fast. I don't have any problem scrolling TextViews in Mail or
with windows in the Finder -- they're very fast. I would guess that they
render to an NSImage and then use -compositeToPoint:fromRect:operation:
with NSCompositeCopy to copy the altered data to the document view. Or
they have the alphabet pre-rendered and just composite the bitmaps of each
glyph. Or maybe they do both.
But you can't do that sort of thing if you want to draw a bunch of
sub-views in your document view, in order to take advantage of the
responder chain. Responding to mouse clicks would mean laying out a bunch
of tracking rectangles over your "sub-views" and managing the co-ordinates
yourself, just like with QuickDraw.
Brent
There are two kinds of people in the world, those who divide the kinds of
people in the world into two kinds, and those who don't.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.