Re: NSView patch

[Matt Rice]

On Mon, Feb 23, 2009 at 8:37 AM, Nicola Pero
<address@hidden> wrote:

>> unfortunately for our unsuspecting view, subviews which were at some
>> odd coordinate were left as needing display,  when their super views
>> noticed that they were still marked as needing display and redisplayed
>> only those. (in case a view calls -setNeedsDisplay: on something while
>> in drawRect:)
>
> Yes.  This is where there seems to be an error in the logic in the current
> code - ie,
> support for overlapping sibling views is missing.  If a view is redrawn, all
> views
> that above it must always be redrawn too. ;-)
>
> So, if view A is still marked as needing redisplay, and view B is on top
> of it, both A and B must be redrawn, even if B is not marked as needing
> redisplay.  The current code in the GUI doesn't do that; it iterates over
> the
> subviews, and redraws the ones marked for redisplay, but doesn't redraw
> any other one, without considering that if we support overlapping sibling
> views,
> it also needs to redraw all the other views that are on top of the ones
> being
> redrawn. ;-)
>
> In the standard situation where there are no overlapping views, adding
> support
> for overlapping sibling views in that way would mean a lot of pointless
> redrawing
> though - because if view A is redrawn, then all views following it in the
> list of subviews
> would be redrawn even if they are not actually overlapping A.  In other
> words,
> any time anything changes in a window, everything needs to be redrawn. :-(
>
> Presumably the code could try to only redraw views that are over (according
> to the list of views) *and* that overlap the ones that needed to be redrawn.
> I'm not sure how to do that computation efficiently though ... I suppose for
> every view that is redrawn, you also iterate over all the views above it
> looking for ones that overlap, and redraw these as well.  That sounds
> potentially
> expensive (N^2) if there are a lot of subviews ... :-(
>
> Thanks
>

Yeah I think that this is something that it shouldn't do as per the
documentation you quoted earlier, but in theory it should work alright
if you are very careful in the views you use,
and make sure those don't set super views as needing display, (though
you could setNeedsDisplayInRect: on the view which contains the
overlapping view alright).

it would never work for something like overlapping
NSBlinking12OClockView  where a digital clock blinks "12:00" on a
timer. though you could allow it to only blink the 'top-most view'
e.g. the key view if you wanted

but the views are in a split view and a scroll view, and most stuff
out there just has one view which encompasses the area

and as I said in the bug report, i'm probably going to remove
overlapping views whenever I get automated graph layout in the diagram
view, and remove the ability to drag them around, I was mostly
investigating this due to the performance implications of drawing
subviews multiple times..