← Back to team overview

kicad-developers team mailing list archive

Re: wxDC zoom break through.

 

Wayne Stambaugh wrote:
Dick Hollenbeck wrote:

Wayne Stambaugh wrote:

After a few false starts, much grepping through the wxWidgets source
code, and a lot of frustration, I have finally solved the zooming issue
using wxDC. I had to turn off the wxAutoBufferedPaintDC in the
INSTALL_PAINTDC() macro and disable the new bitmap grid drawing code to
get it to work properly but it does appear to be fully functional. I
would like to know if anyone else is interested in taking a look at to
see if I missed anything. I believe I have managed not to break
anything using the current drawing code so committing it to SVN should
be reasonably safe. I added an cmake option to make it easy to enable
and disable it. I would like it get some heavy testing to make sure it
is at least the equivalent to the current drawing code. Once it has
been tested, I recommend removing all of the existing coordinate
manipulation code to get rid the unnecessary function calls and remove
all of the ugly conditional compilation code as well. I also plan to
add a software switch to allow testing of the wxGCDC without recompiling
so that performance can be compared to the wxDC rendering see if moving
to wxGraphicsContext::Draw() code makes any sense. I know removing
wxBufferPaintDC and the bitmap grid drawing are a step backwards in
performance but it is big step forward towards removing a lot drawing
code complexity and making the move to wxGraphicsContext achievable. I
also believe that removing them is only temporary until I can figure out
what the difference between wxPaintDC and wxCientDC is in terms of
setting up the DC to calculate the coordinates correctly. I have a
sneaking suspicion that this is also why calling Refresh() or Update()
on zooming doesn't work correctly. If there are no objections, I will
commit these changes in the next couple of days.

Wayne


Sounds fine to me. INSTALL_PAINTDC is not pretty IMO.

The only thing I don't march with you on is when you say "wxGraphicsContext's performance will be adequately judged simply by using wxGCDC".


True, it will not be an accurate performance metric. I don't know how much of a difference using floating point coordinates, transforms, paths, etc. will have on the drawing speed of wxGraphicsContext. However, it does use the platform specific advanced drawing library ( Cairo on GTK, GDI+ on Windows, and Core Graphics on OSX ) to perform the drawing instead of the old drawing libraries that wxDC uses. This should give us a rough idea if wxGC is even usable on all platforms. If rendering speed using the advance drawing libraries for the Kicad video sample goes from 100ms to 5s then I seriously doubt wxGC will be usable even with a full blown wxGC implementation. This should give us some indication whether or not to even pursue a wxGC implementation.


This is not clear to me. (Nor would I assess the speed of a runner that is wearing a snow suit and snow boots).

I don't know that wxGCDC brings any value at all long term to be candid. And this is saying nothing about wxGraphicsContext, of which I am quite hopeful.


If performance is not an issue, than I agree that taking full advantage of wxGC makes perfect sense. This fix is an important step in getting us there. It removes (hopefully) all of the coordinate scaling and offsetting out of Kicad and into the device context.

Wayne


It seems we are in full agreement then. A migration ( slash testing ) phase is a way to test the waters. But remember the entire OSX implementation of wxWidgets is now on wxGraphicsContext if I recall correctly.

Already.

Or at least non wxGraphicsContext and true wxGraphicsContext calls map to the same underlying API. So we should not expect any significant performance change on that platform. On other platforms things might slow down a little initially, but could improve after the stroking support is fully utilized and the actual number *and nature* of API calls is changed as a result of a rewrite (after the migratory / test code) to utilize wxGraphicsContext in the way it is intended (not through wxGCDC ).


My prediction is that it will run faster on faster computers, and that faster computers will continue to get cheaper......

and that the adoption of Kicad among corporate users (with these fast computers) will enhance the amount of corporate sponsorship, which in turn will improve the software faster. So a corporate adoption strategy is more beneficial to the project than simply targeting the software only for hobbyists with 10 year old computers having 400 pixels per row screens and 500 MHz clocks.


And when a company does step up and sponsor work in this project costing tens of thousands of dollars, it is difficult for it to even hear that purchasing a $20 mouse is a problem, not to mention a $200 computer.

(You can tell that this has been bothering me for awhile.)

Folks need to share in the costs of their own happiness.

Dick








Follow ups

References