kicad-developers team mailing list archive

[jean-pierre charras - INPG <jean-pierre.charras@...>]

Dick Hollenbeck a écrit :
> Wayne Stambaugh wrote:
> > 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). 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.
> >
>
> Good information. Sounds like a good bit of work to change strategy,
> and tough to straddle a fence while doing it. But if there are no
> gotchas this seems like a reasonable direction for the package to evolve
> towards.
>
> > 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.
> >
>
> There are always folks who will not touch the SVN version until we say
> it is a release candidate. These extra users come on board and
> essentially become testers of the first RC's. I think we can use that
> extra testing man-power to find and fix any problems with your changes
> along with all the hundreds of others. The first RC may not be
> perfect. That is my opinion, so I would lean towards getting it out
> there. Given your remarks above, this zoom code would not otherwise
> exist if we pursue a path of pushing it out of App code and down into
> wxDC. So if not now, then when?
I agree.
I think you can commit this new code ASAP.
the first RC will have a lot of new and complex functions that can have 
some bugs.
But if we wait until no bugs, the new RC never happens.
> And if anybody complains, we can always give them a discount. :) In
> fact, discounts of 100% are feasible.
>
> Dick
Discounts of 100% are feasible only for 2 licenses and more.
(until now we earned $ 0 million , but expect $ 0 billion tomorrow)

--
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 :
Grenoble Image Parole Signal Automatique (GIPSA - INPG)
Grenoble France