kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 4/14/2012 2:14 PM, Dick Hollenbeck wrote:
> 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
> 

Excellent!  Thanks for fixing this.

Wayne