The main view of my application is an NSScrollView. When the document size is large, say 24k x 17k pixels (approximately 30 x 30 landscape pages), when the magnification of that view changes from normal size (1.0) to a reduced to fit (≈0.05), my [NSView drawRect:] for the view is being called thousands of times for very small tiles.
A single iteration over what needs to be drawn is time-consuming, even when bounds intelligently filtering what needs to be drawn. Thousands of iterations are glacially slow – not tolerable.
This screenshot shows the multitude of tiles, filling each one with a random color.
Screenshot showing the tiny tiles the view is being broken into
An interesting thing is that once it has drawn those thousands of tiles, the NSScrollView no longer tiles the view but instead calls my drawRect: with a rect that covers the whole view. It seems like it may be a bug with NSScrollView.
In addition, if the magnification only changes in relatively small increments say a factor of 1.5 – 2.0, there is never a proliferation of tiles, but typical-sized tiles.
So, I have two questions:
- Is this a bug in NSScrollView?
- Is there a way to prevent NSScrollView from tiling its contents?
Here is a paired-down Apple Sample project that demonstrates the issue: Link to my NSTextView example
To see the issue, build the app and run it. Once running, choose ‘Normal Size’ from the View menu. After it refreshes, choose ‘Reduce to Fit’ from the View menu and you will see that an excessive number of tiles are drawn.
Todd Stanley is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
5