Re: NSCell and partial redraw
Re: NSCell and partial redraw
- Subject: Re: NSCell and partial redraw
- From: Patrick Mau <email@hidden>
- Date: Tue, 31 Aug 2010 18:03:45 +0200
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 (email@hidden)
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:
This email sent to email@hidden