On 31 Aug 2010, at 17:03, Patrick Mau wrote: > Hallo Fritz > > Thanks a lot for your comments. I just have a few remarks to clarify what I > meant. > Please see below. > > On 31.08.2010, at 17:26, Fritz Anderson wrote: > >> 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. > > I understand that. But by the time the they should redraw, they know the > NSView they belong to and the cellSize they need to > layout themeselves in. If a NSView decides to draw them inside "drawRect:", > it would call the NSCell's drawing code passing > the frame and possible itself as the control view. > >> 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. > > Let's just assume that when my NSView calculates that only halve of the > NSCell's frame intersects the dirty rect, > it should somehow share that information with the NSCell's implementation of > the actual drawing code. > > So, my question was trying to focus on best practices of how to tell the > NSCell's "drawWithFrame" that > it should draw itself in the cellFrame, but also reduce the drawing > complexity by having access to the NSViews's > dirty region that triggered the call in the first place. > > I could just provide a property of type NSRect in the controlView and set > this to the intersecting > rectangle of the dirty area and the cellFrame. > > The cell would than use that property inside "drawWithFrame" for optimization. > > But this seems ugly to me, because every NSView that would use any of my cells > would have to provide that property. This is wrong, in my opinion. > > I also know that I can clip drawing regions, but what I really want to do is > minimize draw calls. > > By the way, my NSCell draws parts of a bar chart and therefore it would be > great to know which > bars are affected by the dirtied region that needs redrawing. It would reduce > a lot of elements > I would otherwise at to an NSBezierPath. > > I'm not asking for code here, I have most of it working already, but it > always redraws the complete cell. > Any comments or sharing of ideas would be greatly appreciated.
I think you want to look at -controlView/-setControlView. The default NSCell implementation of these methods does nothing, but you can override to store a reference to the control view, and get dirty rect etc. info out of that. Mike._______________________________________________ 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
