|
From: | Fred Kiefer |
Subject: | Re: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls |
Date: | Wed, 25 Jan 2012 00:49:54 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 |
On 24.01.2012 20:01, Eric Wasylishen wrote:
Ugh, r34614 introduced more bugs itself (resizing the panes in Grr can make the table headers change size). I should know this would happen if I tried to change things during a code freeze...
This is a strange problem to be caused by that change. I can reproduce this problem with Grr and when reverting your change it is definitely gone. Still I don't quite see how the two are related.
I did some debugging here and it seems that the problem starts when we get values below zero. From that I would conclude that the issue is rather that due to rounding errors in the transformations we return values that are not suitable for the scroll view. We could try to avoid this by doing the transformation to pixel space and back again before doing the clipping. That is move this code up before the load of if statements in this method. This of course will only work when the bounds of the clip view are pixel aligned. We need to ensure that in some other way. With that change in place Grr behaves again as before.
Of course there may be other applications that get affected.
Fred, do you think we should just ship the release with copy-on-scroll disabled? That would fix the flickering in FisicaLab reported by German, and the blurring I reported here in zoomed TextEdit. We could turn it back on after the release and try to fix those bugs.
I replied to that question already in my last mail. And I am really not sure what the best way forward is here.
[Prev in Thread] | Current Thread | [Next in Thread] |