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. Thanks a lot Patrick _______________________________________________ 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
