• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Quartz/memory benchmarks...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.
  • Follow-Ups:
    • Re: Quartz/memory benchmarks...
      • From: Charles Jolley <email@hidden>
References: 
 >Re: Quartz/memory benchmarks... (From: Charles Jolley <email@hidden>)

  • Prev by Date: view co-ordinate scaling
  • Next by Date: re: view co-ordinate scaling
  • Previous by thread: Re: Quartz/memory benchmarks...
  • Next by thread: Re: Quartz/memory benchmarks...
  • Index(es):
    • Date
    • Thread