kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

jean-pierre.charras@... wrote:
> 
> 
> Wayne Stambaugh a écrit :
> 
> <skipped>
>> 
>>
>> jean-pierre. charras@gipsa- lab.inpg. fr
>> <mailto:jean-pierre.charras%40gipsa-lab.inpg.fr> wrote:
>> Interestingly,
>> printing in Kicad uses wxDC scale, offset, and axis polarity then calls
>> the unscaled drawing functions in gr_basic.cpp. I don't understand why
>> drawing to the screen is not done the same way.
>> Wayne
>>
> Just because it did not work.
> Printing draws the full sheet.
> *So no coordinates overflow can happen when printing.*
> 
> On screen this was very different:
> When using DC zoom functions, overflows in screen coordinates happen for
> almost all graphic items at low zoom levels.
> unfortunately, wxDC *does not clip* coordinates of graphic items, just
> it scale them.

The clipping region support on Windows must be broken (not surprised)
because the source file msw/dc.cpp shows SetClippingRegion() using the
windows GDI API functions ::CreateRectRgn() and ::ExtSelectClipRgn() to
set the clipping region. It also checks the returns of these API calls
for errors and calls wxLogLastError() so if it is failing we should see
a log window pop up and display the error message. wxWidgets does not
perform any limit testing of the scaled coordinates. There is no way of
knowing if Windows checks the coordinate limits internally. But there
is clipping using the native clip support in Windows. I would imagine
that clip support on other platforms is implemented natively as well.

> So, mainly under Windows (screen coordinates were handled using 16 bits,
> at least under W95 and W98 (when kicad was using wxWidgets) using wxDC
> internal scale was not possible.

I hope we are not still trying to support W95/W98. Does wxWidgets even
support them anymore?

> But i found overflows problem also using Linux (with arcs and circles,
> although Linux uses 32 bits coordinates)
> *This was the reason* I wrote gr_basic that handle zoom but mainly clips
> graphics lines and polygons before calling wxDC draw functions.
> 
> Clipping inside Kicad is now mandatory for polygons (used in zones)
> under Linux.
> (and there are also problems, as you know, under Windows WP with large
> coordinates)

This is why I proposed creating a custom DC (KicadDeviceContext) that
looks like wxDC to drawable objects but handles the clipping, scaling,
offsetting, etc according to Kicad's requirements.

> 
> So the first work using wxGCDC or an other library is to test these
> overflow problems.
> Well, the first requirement of a graphic library is: it must work
> without overflow, on large coordinates values (full 32 bit values).
> Currently it is not the case with wxDC, and I do not knows if wxGCDC 
> works (i.e. if it clips large coordinates)
> Unfortunately, I am not sure wxGCDC clips coordinates.

It appears, at least for GDI+ on windows that is uses GDI+'s clipping
implementation. I don't know if GDI+ clipping suffers from the same
problem that the older GDI clipping does. One difference is all of the
coordinates are floating point values and not integers.

Wayne

> 
> -- 
> Jean-Pierre CHARRAS
> 
> Maître de conférences
> Directeur d'études 2ieme année.
> Génie Electrique et Informatique Industrielle 2
> Institut Universitaire de Technologie 1 de Grenoble
> BP 67, 38402 St Martin d'Heres Cedex
> 
> Recherche :
> GIPSA-LAB - INPG
> Rue de la Houille Blanche
> 38400 Saint Martin d'Heres