On 31 Aug 2010, at 4:59 AM, Patrick Mau wrote:
> Let's assume I have a custom NSView that will use to custom NSCell instances
> to render its contents.
> Now, if "drawRect:" is called on the NSView, I get the dirty rect that needs
> to be redrawn.
>
> The NSCell class on the other hands uses:
>
> - (void)drawWithFrame:(NSRect)cellFrame inView:(NSView *)controlView
>
> Where "cellFrame" is the complete frame the NSCell should use to draw itself
> into.
>
> Should I intersect the dirty region of the NSView and somehow add additional
> functionality to the NSCell to maintain the dirty region?
>
> Or should I ask the "controlView" for the region and maintain it there?
>
> How do people implement NSCell subclasses when the goal is to minimize
> the redraw code needed when the cell is drawn?
I'm not sure if this fully answers your question, but cells are extremely
lightweight things that know how to draw themselves, receive mouse events, and
keep a limited amount of state about appearance and value. They are owned by
NSViews, which squirt the cells onto the screen wherever they are wanted. Cells
don't know anything about view management, such as dirty rects. They don't know
anything about their positions or sizes. They don't even know what views own
them.
The rectangle passed into the NSCell draw… methods is the full frame of the
cell; it's the only way the cell has of knowing how to lay itself out. It
shouldn't have to know about its dirty region. That imports view-management
behavior into the cell, and not doing view-management is the whole point of
having a cell. Do what you like, but you'd be fighting the framework.
I don't know what you mean by "should I intersect…." Do you mean whether you
should _calculate_ an intersection rectangle and pass that into the API? No.
The cell can't use that information. Do you mean whether you should take the
rectangle passed into drawRect:, iterate through the cell frames (a list _your
view_ keeps), and draw only the ones that intersect the dirty rect, however
little? Yes, you should.
— F
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
