[Drawkit] Scaling issues

[Graham Cox]

On 23 May 2008, at 8:51 am, Brad Larson wrote:

> I was able to finish the file import for our XML-based pattern file  
> format and tried out loading a few files.  I ran into some issues  
> with grid and drawing scaling that we started to touch on earlier.
>
> Our pattern files typically have a large dynamic range.  That is, we  
> draw things out in microns, but the structures they make might be  
> centimeters across.  This causes a problem with scaling, because we  
> either have to start with small units and zoom way in to deal with  
> fine features or start with larger units and zoom way out to see the  
> whole pattern.
>
> I tried setting the units to match the true dimensions of the  
> objects we're drawing using
>
> [currentDrawing setDrawingUnits:@"Microns"  
> unitToPointsConversionFactor:(kGCGridDrawingLayerMetricInterval /  
> 10000)];
> DKGridLayer* grid = [[DKGridLayer alloc] init];
> [grid setSpan:(kGCGridDrawingLayerMetricInterval/100)  
> unitToPointsConversionFactor:(kGCGridDrawingLayerMetricInterval /  
> 10000) measurementSystem:kGCMetricDrawingGrid  
> drawingUnits:@"Microns" divisions:10 majors:2 rulerSteps:2];
>
> and that created a really tiny grid and really tiny structures on  
> load, because they were displayed at their real size.  That's not a  
> problem, but when you zoom in, because everything is just scaled  
> proportionally, the grid lines are so large that there's no white  
> space in between.

Yes, I can see why that will happen. You probably don't want to set  
the grid's span to such a tiny value. Instead set it to something  
usable and give it a larger number of divisions to give you some  
usable grid.

> Also, the object handles take up nearly a quarter of the screen and  
> are unusable as a result.

Hmmm, that's a bit strange. The handle size is not dependent on the  
grid, and does account for scaling normally, so this should not occur.  
Smells like something's not quite right there.


> Then I ignored the real dimensions and said that 1 micron equals one  
> point
>
> [currentDrawing setDrawingUnits:@"Microns"  
> unitToPointsConversionFactor:1];
> DKGridLayer* grid = [[DKGridLayer alloc] init];
> [grid setSpan:(1 * 100) unitToPointsConversionFactor:1  
> measurementSystem:kGCMetricDrawingGrid drawingUnits:@"Microns"  
> divisions:10 majors:2 rulerSteps:2];
>
> and that created larger features, but in order to see the whole  
> pattern I needed to zoom out quite a bit.  I ran into a problem  
> there because I hit the GCZoomView's minimumScale and it wouldn't  
> let me zoom out any more.  Why are there minimum and maximum zoom  
> scales?  They don't seem to serve a purpose.  I tried subclassing  
> DKDrawingView to remove them in my subclass, but ran into a "- 
> [NSRulerMarker initWithRulerView:markerLocation:image:imageOrigin:]:  
> no image given.  NSRulerMarkers must have an image." exception when  
> trying to use my subclass for the DKDrawingView in IB.  I just gave  
> up and changed the minimum zoom to 0.0 in GCZoomView to get around  
> this.

Why are there limits - good question. I don't know ;-) But there are  
probably practical limits because of usability issues, which seems  
like what you've run into.

I wouldn't set a minimum of exactly 0 because you'll get a division by  
zero error at some point - but some very small value should be OK.

> At the large scale, the grid completely disappears.  The selection  
> handles are now so small that you can't click on them.  Also, I  
> pegged one CPU core at 100% just trying to select a couple objects  
> at that zoom factor.

By "large scale" do you mean zoomed in or zoomed out?

>
> It looks like we might want to consider redrawing the grid on a  
> change of scale, to make sure that the linewidth is always 1.0, no  
> matter the scale.  I haven't looked into the selection handles  
> (DKKnob?) yet, but it seems like making them aware of the scale  
> factor would also allow you to redraw them with constant sizes and  
> linewidths.  If you have any suggestions, I'd be glad to look into it.

DKKnob is aware of the scale factor. It doesn't compensate for it  
exactly, because I found that allowing it to scale to some extent was  
much more usable, especially with small objects and high zooms.  
Currently it scales at a rate of about 1/3rd of the view's scale. If  
that's not happening, it seems like there is some disconnection  
between the DKKnob intance and the view - not sure exactly why that  
would be.


I may need to give some more consideration to what happens to the grid  
over a wider zoom range. The current zoom range is only 100:1 which is  
fine for ordinary drawing-type apps but may not be enough for  
scientific applications. I'll get back to you about this.

> Also, what would be your recommended process for automatically  
> setting the scale to fit the drawing size on load of a drawing from  
> disk?

The easiest way is probably just to invoke -zoomFitInWindow: on the  
view after it's all loaded in.


cheers, Graham