kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/14/2012 10:06 AM, Wayne Stambaugh wrote:
> On 4/13/2012 3:03 PM, Dick Hollenbeck wrote:
>> On 04/13/2012 12:00 PM, Wayne Stambaugh wrote:
>>> On 4/13/2012 10:04 AM, Dick Hollenbeck wrote:
>>>>> Also, you may want to
>>>>> change Mils2iu to use wxRound() so it will work for negative values.
>>>> wxRound()'s use of C lib's round() seems like overkill to me.
>>>> Since the objective is to produce an integer, not a double, there is an easier way that
>>>> has the possibility of letting the compiler do some of the work, i.e. in advance, on
>>>> constants,
>>>> without the overhead of a mandatory floating point function call.
>>>>
>>>> See my latest DMils2iu() as a suggestion.
>>>>
>>>>
>>>> Dick
>>> wxRound may be overkill but it does one important thing that will become
>>> apparent when I commit the code that scales the PCB_SCREEN zoom factors
>>> to work properly with nanometer internal units.  In debug builds,
>>> wxRound tests if the floating point result is within INT_MIN and INT_MAX
>>> and raises an assertion if it is not.  I found out that this assertion
>>> occurs in the wxDC::LogicalToDevice() functions when zooming way out
>>> when Pcbnew is compiled for nanometers.
>> You are saying that this assert fires when precisely within wxDC::LogicalToDevice(), still
>> within wx not inside gtk, correct?
>>
>> Can you give a filename and approximate line number of code please?
>>
>> Then we can and should add similar asserts.  wxRound() use of c lib round() is not
>> warranted, and removes compile time code reduction opportunities.
> Here's the back trace on the debug build Windows using wxWidgets 2.9.3:
>
> #0  0x7c90120f in ntdll!DbgUiConnectToDbg ()
>    from C:\WINDOWS\system32\ntdll.dll
> #1  0x0086b0cc in wxTrap ()
>     at e:/src/wxWidgets-2.9.3/src/common/appbase.cpp:1015
> #2  0x0086b138 in wxDefaultAssertHandler (file=..., line=120, func=...,
>     cond=..., msg=...) at e:/src/wxWidgets-2.9.3/src/common/appbase.cpp:1044
> #3  0x0086b888 in wxOnAssert (
>     file=0xb8d428 "E:/MinGW/include/wx-2.9/wx/math.h", line=120,
>     func=0xb8d901 "wxRound",
>     cond=0xb8d400 "x > INT_MIN - 0.5 && x < INT_MAX + 0.5",
>     msg=0xb8d3c0 L"argument out of supported range")
>     at e:/src/wxWidgets-2.9.3/src/common/appbase.cpp:1145
> #4  0x0094a363 in wxRound (x=2672080000)
>     at E:/MinGW/include/wx-2.9/wx/math.h:120
> #5  0x00727a29 in wxDCImpl::DeviceToLogicalXRel (this=0x1def4d98, x=1052)
>     at e:/src/wxWidgets-2.9.3/src/common/dcbase.cpp:390
> #6  0x00a55727 in wxDC::DeviceToLogicalXRel (this=0x22dd50, x=1052)
>     at E:/MinGW/include/wx-2.9/wx/dc.h:999
> #7  0x005fb11a in EDA_DRAW_PANEL::SetClipBox (this=0x1de96e58, aDC=...,
>     aRect=0x0) at e:/src/kicad-testing/dev-branch/common/drawpanel.cpp:455
> #8  0x005fb4b9 in EDA_DRAW_PANEL::DoPrepareDC (this=0x1de96e58, dc=...)
>     at e:/src/kicad-testing/dev-branch/common/drawpanel.cpp:494
> #9  0x005fb542 in EDA_DRAW_PANEL::OnPaint (this=0x1de96e58, event=...)
>     at e:/src/kicad-testing/dev-branch/common/drawpanel.cpp:508
>
> The assertion is happening in wx/math.h in the wxRound() function when
> repainting the display after the zoom.  I will shortly be committing the
> changes that scale the worksheet reference and title block and the
> Pcbnew zoom and grid sizes to accommodate nanometers so that you can
> play around with it to get a feel for some of the issues that will need
> to be resolve before nanometers can become the default internal units
> for Pcbnew.

I was able to duplicate this shortly after you reported it yesterday, and found that that
patch I sent to the list fixed this one.

We were assigning m_ZoomList[0] to an integer, and the value being assigned was 0.5, so
when this conversion took place to int, you ended up with zero.

Then that zero was sent into wx and was used to calculate some scaling constant in there,
the 0 went into the denominator of a calculation, leaving the dividend at infinity.

So anything coming in after that would blow up because it was being multiplied by infinity.

I no longer see this error, but certainly the zooming is not smooth yet.  I think we are
just at the next in a series of hurdles which we'll have to knock over.

Dick