kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

jean-pierre charras - INPG wrote:
> Wayne Stambaugh a écrit :
>> Warning, rant ahead. If you are only interested in the new zoom stuff,
>> skip down to the last paragraph. However, if you indulge me, I would
>> like to impart some wisdom I gathered on my travels through the inner
>> workings of Kicad and wxWidgets. Let me start by saying that in order
>> to get the new zoom features implemented I violated at least a half
>> dozen of my personal coding rules not the least of which are don't
>> reinvent the wheel and keep it simple. But I was concerned about Dick's
>> eye sight, so I acquiesced.: } In my travels through the Kicad and
>> relevant wxWidgets source code, I came to the following conclusion that
>> all of the drawing coordinate scaling (zooming) and offsetting code in
>> Kicad is unnecessary and redundant. For all the developers who in the
>> past have voiced concerns about using floating point for drawing
>> coordinate calculations, be assured that it is already happening inside
>> wxDC. Granted, if no changes to the logical or user scalars are made to
>> the device context, then the coordinates get multiplied by 1.0 * 1.0.
>> They still get converted to floating point then back to integer. In
>> fact, all of the scaling code performed as integers in Kicad just adds
>> clock cycles to what wxDC already does. There is no performance gain by
>> doing this. Not convinced, check out the "drawing" sample shipped with
>> the wxWidgets source. It does not scale the drawing object coordinates
>> before calling the wxDC drawing methods. All it does to change the size
>> an position of the drawing is manipulate the user scale and logical
>> offset of the device context. Everything else is taken care of by wxDC
>> automatically. wxDC even provides functions to translate coordinates
>> between the logical and display units. All of this capability appears
>> to have been available in wxDC all the way back to at least 2.2.9 in
>> December 2001 (that was the oldest wxWidgets help I could find). The
>> drawing sample works the same on Windows and Linux (64 & 32 bits).
>>
> I am afraid drawing sample does not work on Windows (i assume you are 
> talking about samples/drawing/drawing.cpp)
> 
> I tested it with only one changes in code to use a coordinate > 65536 
> when drawing a line.
> 
> in MyCanvas::DrawTestLines( int x, int y, int width, wxDC &dc )
> if it called with x = 0x90000 then when
> dc.SetPen( wxPen( wxT("black"), width, wxDOT) );
> dc.DrawLine( x+20, y+30, 100, y+30 );
> is called (at default scale = 1.0), my PC *freezes* (needs a reset!)
> 
> 
> ( dc.SetPen( wxPen( wxT("black"), width, wxSOLID) );
> dc.DrawLine( x+20, y+20, 100, y+20 );
> called with x = 0x90000 runs Ok).
> 
> (wxMSW 2.8.9 compiled with gcc 4.2.1, release mode, under XP SP3)

I confirmed this on my system as well using GCC 3.4.5. Wow, a complete
hard lockup of the system. Even the three fingered salute didn't work.
Just to confirm that it was not a problem with MinGW, I built wxWidgets
and the drawing sample with Visual Studio 2005. The same failure
occurred. So I booted into Linux (Debian Testing, wxWidgets 2.8.7, GCC
4.3.2) to see if the same problem exists. Apparently this is a wxMSW
issue only. wxGTK seemed perform fine. I search the wxWidget bug
tracker and did not find anything so I submitted the bug. Someone with
OSX should confirm if the problem exists there.

Wayne

> 
> Be carefull about clipping code in gr_basic.
> 
> Unfortunately all coordinates in samples using wxDC use small values 
> and, of course, without patching them there is no problem.
> All my problems where found when using coordinates > 4095 (in arcs) and 
> specially > 16 bits. (at scale 1)
> 
>> Can someone with OSX confirm that wxWidgets drawing sample works there as
>> well? If so, I think that all of the code in gr_basic.cpp and all of
>> the scaling and offset calculation code scattered throughout Kicad
>> should be remove and pushed down to wxDC where it belongs. This would
>> greatly simplify drawing in Kicad and having the added bonus of allowing
>> the use of some of the more advanced wxDC type classes such as
>> wxGraphicsContext or wxBufferedDC. I am willing to take on the task
>> (although it will probably take me a few months to complete) after the
>> next version of Kicad is released. I'll stop ranting now, but I have a
>> few more in store for a later date.
>>
>> Now on to the new zoom code. Due to the coordinate scaling being
>> scattered throughout Kicad, I did not implement the new zoom code with
>> #ifdefs all over the place. I started down that path, but it was
>> quickly becoming an awful mess and a pain to enable and disable. I
>> tested everything I could think of that is zoom related and it seemed to
>> work fine for me. There may be some slight single pixel drawing issues
>> due to rounding since I had to use a scalar to get a zoom of 1.5 (known
>> as zoom level 15 in the new code). I have not committed the new code to
>> SVN yet due to talk of a new release in February. If no one has any
>> objections, I will commit the code in the next few days. I believe that
>> the risk is fairly low but I will wait. If the consensus is to wait
>> until after the new release, I'll hold off committing until then.
>>
>> Wayne
>>
> 
>