kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/06/2012 03:15 PM, Dick Hollenbeck wrote:
> 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


Please note that since the virtual space is now clamped, the mouse pointer may not always
stay at the screen center, since as you zoom out you soon hit the limits of the virtual
space.  However I would hope that the mouse pointer is not moving within the virtual
space, i.e. it should be staying at the same virtual coordinate.   The virtual coordinate
lock in may not be achieved without moving the mouse pointer on screen under circumstances
of approaching the "edge of space".


Approaching the "edge of space" is not something we have had to deal with in the past.


Dick