Re: Single vs. multiple NSView
Re: Single vs. multiple NSView
- Subject: Re: Single vs. multiple NSView
- From: Ricky Sharp <email@hidden>
- Date: Fri, 23 Jul 2004 06:24:17 -0500
On Thursday, July 22, 2004, at 11:24PM, Chris Hanson <email@hidden> wrote:
>
On Jul 21, 2004, at 4:51 AM, Ricky Sharp wrote:
>
> - background image (opaque; fills entire window)
>
> - some other image (transparent areas, so composited in)
>
> - button widgets (also with transparent areas, drop shadows)
>
> - help tag, but only if I need to grow my own solution. This could
>
> either be done as a custom NSView or an overlay window.
>
>
From this, it sounds less like your views will overlap and more like
>
they'll form a containment hierarchy. NSView will do a lot of work for
>
you in this case.
>
>
I'd probably start out with NSViews and then refactor to use NSCells
>
instead if I found I actually needed the extra performance. However,
>
if you're targeting Panther and later, there are additional ways to
>
improve view performance beyond just switching to cells or other
>
lighter-weight mechanisms.
>
>
For example, -[NSView getRectsBeingDrawn:count:] from within -drawRect:
>
will get you an array of dirty rectangles to redraw in a view, so you
>
aren't redrawing the whole thing every time. You can also use the
>
parameter to -drawRect: to reject objects that don't need to be
>
redrawn. And of course you could use -setNeedsDisplayInRect: instead
>
of just -setNeedsDisplay: to invalidate a portion of a view.
>
>
Another idea: Say you can divide your screen into a "playfield" and
>
"controls." Your controls are relatively static, but your playfield is
>
very dynamic. You can make your controls real controls or views, but
>
make your playfield just one view that manages all of its own drawing
>
internally and get the best of both worlds.
Thanks Chris,
After many ideas posted both here and on quartz-dev, it appears the best overall solution is to go with a single custom NSView. The view will maintain an NSImage that represents the current snapshot of the state of the app (i.e. what screen it's on, what widgets are shown, etc.). In the view's drawRect: it will be a simple "blit" of the NSImage clipped to the incoming rect.
Each widget will simply wrap an NSImage. The original source(s) of the image will also be cached by the widget. For example, a button widget can have up to four appearences (enabled, disabled, mouseover, pressed) which will most likely come from a 4-page PDF document. I'll thus have up to 4 cached PDF Page Refs. The NSImage would then contain the [rasterized?] version of the proper PDF page.
I think what I just wrote is close to your playfield idea?
I'ts kinda funny things are turning out this way. The Carbon version does almost this exact thing where I have GWorlds rather than NSImages.
In terms of optimizations, I will be at least requiring 10.3, so am definitely keen on using setNeedsDisplayInRect and ensuring I write the most optimal code.
Finally, the only drawback in not going the multiple NSView route was that I was experimenting in having a custom NSViews and writing an IB palette. That would allow me to use IB to lay out the entire UI, set my custom properties, etc. Although, I guess I could still do that where the custom NSViews are simply proxies for the real widgets. Don't yet know what I think about that :)
Thanks again to all that has helped me out so far; it's making the transition from Carbon to Cocoa all that easier.
Rick Sharp
Instant Interactive(tm)
_______________________________________________
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.