[Drawkit] Scaling issues

[Brad Larson]

On May 22, 2008, at 10:07 PM, Graham Cox wrote:

>
> 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.

The problem is more that 1-point-wide grid lines get blown up into 50- 
pixel-wide lines at that zoom factor.  This will happen to a lesser  
degree with anyone zooming in on a fine feature at a higher  
magnification than the one at which the grid lines were originally  
drawn.  Scaling the entire grid, including linewidth, can be  
problematic, which is why I think redrawing the grid at a  
magnification change is the way to go.  Testing it out, I don't think  
it will be that much of a performance hog.

>
>> 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?
>

Sorry, zoomed out.  After running the program through Instruments, it  
looks like the a whole lot of processor cycles are being spent in  
[DKDrawableObject pathBitmapInRect].  That method appears to rasterize  
the object shapes to perform hit detection, and the size of the bitmap  
seems to be set by the original zoom factor, so huge bitmaps are being  
created as you drag the mouse for the selection rectangle on this  
drawing.  Maybe the bitmap hit testing could take the scale into  
account, creating bitmaps whose size only matches the size in pixels  
of that area at the current scale factor, then translate that scaled  
bitmap to the hit testing coordinates being fed in.

What caused you to go with a variant of the method described here:  http://lists.apple.com/archives/cocoa-dev/2004/Sep/msg00698.html 
  as opposed to the mathematical model you proposed here: http://lists.apple.com/archives/cocoa-dev/2004/Sep/msg00696.html 
  ?  I haven't checked fully, but did you go with some of the  
optimizations that Uli Kusterer suggested in that thread?

>>
>> 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 haven't taken a look at DKKnob yet, but I'll see if I can find where  
things are breaking down.

______________________
Brad Larson
SonoPlot, Inc.
3030 Laura Lane, Suite 120
Middleton, WI 53562