kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/18/2012 02:48 PM, jean-pierre charras wrote:
> Le 18/04/2012 20:25, Dick Hollenbeck a écrit :
>>> I am working on this today.
>>>
>>> My gut says this:
>>>
>>>
>>> Basically it comes down to the fact that we cannot describe an area larger than about 12
>>> feet with the nanometer internal units.
>>
>> Jean-Pierre,
>>
>> Can you first look over the attached patch, then play with it.
>>
>> This basically fixes the crash, but I think there's more finishing touches that need to be
>> done.
>>
>> I need to get back to work now.
>>
>>
>> Thank you very much,
>>
>> Dick
> I'll work on that tomorrow.
>
> I also make some tests.
> Under Windows I did now have crashes, but I had other issues.
>
> my opinion is with 32 bits integers we cannot handle more than something like 50 to 70 cm,
> with nanometers units.
>
> I noticed there are a lot of issues when calculating distance between 2 points.
>
> Assuming calculations are using integers, with 32 bits we can handle 2 meters distances only.
> if Xmax and Ymax are Y and Y difference between 2 points,
> only Y or Y max <= 1.4 meter, if sqrt( Xmax*Xmax + Ymax*Ymax) always < 2m.
>
> Because a distance is always >= 0, this means X and Y coordinates must have absolute coordinates < 70 cm.
> With margins around work area, and because Pcbnew and Gerbview use a page only with positive coordinates,
> the active area has a size < 50cm, roughly 20 inches, or A3 or B page size.
>


Well since I put myself back on stage for this, here is what I came up with today, finally
after two weeks of insufficient time to work on it.  I added this comment to
pcbnew/classpcb.cpp line 66:



The largest distance that wx can support is INT_MAX, since it represents
distance often in a wxCoord or wxSize. As a scalar, a distance is always
positive. On most machines which run KiCad, int is 32 bits and INT_MAX is
2147483647. The most difficult distance for a virtual (world) cartesian
space is the hypotenuse, or diagonal measurement at a 45 degree angle. This
puts the most stress on the distance magnitude within the bounded virtual
space. So if we allow this distance to be our constraint of <= INT_MAX, this
constraint then propagates to the maximum distance in X and in Y that can be
supported on each axis. Remember that the hypotenuse of a 1x1 square is
sqrt( 1x1 + 1x1 ) = sqrt(2) = 1.41421356.

hypotenuse of any square = sqrt(2) * deltaX;

Let maximum supported hypotenuse be INT_MAX, then:

MAX_AXIS = INT_MAX / sqrt(2) = 2147483647 / 1.41421356 = 1518500251

This maximum distance is imposed by wxWidgets, not by KiCad. The imposition
comes in the form of the data structures used in the graphics API at the
wxDC level. Obviously when we are not interacting with wx we can use double
to compute distances larger than this. For example the computation of the
total length of a net, can and should be done in double, since it might
actually be longer than a single diagonal line.

The next choice is what to use for internal units (IU), sometimes called
world units.  If nanometers, then the virtual space must be limited to
about 1.5 x 1.5 meters square.  This is 1518500251 divided by 1e9 nm/meter.

The maximum zoom factor then depends on the client window size.  If we ask
wx to handle something outside INT_MIN to INT_MAX, there are unreported
problems in the non-Debug build because wxRound() goes silent.

Let:
const double MAX_AXIS = 1518500251;

Then a maximum zoom factor for a screen of 1920 pixels wide is
    1518500251 / 1920 = 790885.

The largest ZOOM_FACTOR in above table is ZOOM_FACTOR( 300 ), which computes
out to 762000 just below 790885.

=========================================================================


If we plug in the above assumptions into drawframe.cpp AdjustScrollBars() things start to
get a little more stable in the nanometer build.

Now I think we can look for more testing feedback.

Dick