Re: NSScrollView problems in Tiger
Re: NSScrollView problems in Tiger
- Subject: Re: NSScrollView problems in Tiger
- From: John Nairn <email@hidden>
- Date: Fri, 27 May 2005 12:35:59 -0600
On May 27, 2005, at 10:57 AM, Troy Stephens wrote:
Hi John,
This is not a known issue, and it's not yet clear to me why it
might be happening. Are you applying any other transforms, aside
from setting the document view's bounds, elsewhere in the view
hierarchy (e.g. scaling the ClipView's bounds to zoom)? Do you
still have reason to suspect that negative coordinates are
contributing to the problem, or have you now ruled that out?
The only transforms are the setting of the document view's bounds. I
no longer suspect the negative coordinates are the problem because
the region that was bad changed in size as I shrunk the view bounds.
I think Alastair's suspicion that it is round off error sounds right.
There must be limits to precision that can be handled in scrolling
code and for some reasons the limits seem different in Tiger.
I added a "feature" to my code to change the length units in the plot
by re-reading the data with scaling (rather than using transforms
while plotting). The problems go away by scaling the data up to
larger bounds for the view's rectangle.
The precise alignment of the ClipView may also be relevant, as
AppKit handles scroll-copy differently when the clip area is not
aligned on integral pixel boundaries. When you make the following
check:
NSLog(@"clip frame=%@", NSStringFromRect([scrollView
convertRect:[[scrollView contentView] frame] toView:nil]));
Does the result have any fractional components?
Here is one that has problems and it seems to be integral:
clip frame={{1, 16}, {483, 465}}
The bounds and frame for this document's view were
bounds= {{-0.00375384, -0.0160838}, {0.0294479, 0.0283504}}
frame={{0, 0}, {648, 468}}
Disabling copy-on-scroll is a reasonable way to avoid the problem,
but not ideal if your drawing is expensive. Another possible
workaround might be to leave the document view's bounds unscaled,
and instead apply the transforms you need to map from your data
space to view space at the top of the document view's -drawRect:
method, using an NSAffineTransform. (This should not be necessary,
but it might help in this case.)
Disabling copy-on-scroll did fix scrolling (in a few tests), but did
not fix the other problem of loading new data followed by a redraw.
Also, as you mentioned, not copying is expensive for this application
and should not be necessary. I also thought that transforming in
drawRect would be too expensive. Instead, I used the approach
mentioned above where the data is transformed once and then drawn
with new bounds. It is actually useful new feature for my
application, but it would be nice to plot with small bounds too or to
know the limits if that is the problem.
Troy Stephens
Cocoa Frameworks
Apple Computer, Inc.
On May 27, 2005, at 7:51 AM, John Nairn wrote:
I posted two vague questions before and no one had comments. I
think I have more detail now.
When the bounds of the documentViewRect in an NSClipView get
small, scrolling breaks down in Tiger. The problem did not occur
in Panther.
I did some tests and when the view units per pixel got less than
about 0.0025 (or width of bounds about 1 for a view with a frame
width of 400 pixels) the problems start to occur. The scrolling
problems get worse as the width of the bounds get smaller and soon
become severe. The problem is that when the view scrolls, the
scrolling process copies the existing stuff in the wrong way and
the new stuff that is drawn does not fit ro the edges become
corrupted. Telling the scroller to not copy helps (but not a fix)
but should not be needed in a view where copying should work fine
and more efficient.
The view draws fine the first time or after resizing the window,
but it does not draw correctly when scrolling or when updating
after replacing the data with new data and redrawing.
Is this a known bug? Is there a work around?
I am plotting scientific data and sometimes the natural units are
very small. Since the plot may consist of over 1,000,000 Bezier
curves, I hope the work around is not to scale them all before
plotting. It does not bode well for using Tiger for scientific
calculations in nanotechnology?
---------------
John Nairn (1-801-581-3413, FAX:1-801-581-4816)
Web Page: http://www.mse.utah.edu/~nairn
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden