[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay
Re: gui patch for review: -[NSView setBounds*:] - remove setNeedsDisplay: YES calls
Wed, 25 Jan 2012 00:49:54 +0100
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
I replied to that question already in my last mail. And I am really not
sure what the best way forward is here.