Re: NSView drawRect vs. autoscrolling
Re: NSView drawRect vs. autoscrolling
- Subject: Re: NSView drawRect vs. autoscrolling
- From: Tom Waters <email@hidden>
- Date: Mon, 11 Jun 2001 20:53:50 -0700
So, any thoughts on how I can let the copy happen, but be notified of it
in some way so I can call setNeedsDisplay on the single scanline of bad
pixels?
Why weren't any of those methods being called on my view?
On Monday, June 11, 2001, at 08:23 PM, Greg Titus wrote:
>
On Monday, June 11, 2001, at 05:09 PM, Tom Waters wrote:
>
>
> I am wondering how I can have a view, nested in a scrollview, that
>
> draws on itself and stay in synch with the autoscrolling during drag
>
> and drop.
>
>
>
> It seems like there is a race condition here:
>
>
>
> In my drawRect I want to paint a border using [self visibleRect]
>
> during drags. The problem is, when a pending drag causes the view to
>
> scroll, the subsequent drawRect is getting the wrong answer from
>
> visibleRect.
>
>
>
> After some investigation I think this is more likely: the window
>
> system is just copying bits on the screen, assuming that this will
>
> leave the correct image.
>
>
Yep. The latter is what is happening. This is a display optimization so
>
turning it off will slow down display of your app a bit. There is also
>
some hope that Quartz will eventually do this by copying bits all in
>
video memory, so you should be aware that turning off this optimization
>
may hurt you quite a bit more in the future. (That is, you won't see
>
any speedup in your app when/if the Apple people do more here.)
>
>
> Anytime you draw in a view dependant on the enclosing view, the
>
> scrolling mechanism can't optimize the scrolling via copyarea... is
>
> there some place I can turn this off?
>
>
Yes. You want to call -setCopiesOnScroll: on the clip view:
>
>
[[[myView enclosingScrollView] contentView] setCopiesOnScroll:NO];
>
>
Hope this helps,
>
--Greg