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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
