← Back to team overview

kicad-developers team mailing list archive

  1. kicad-developers team
  2. Mailing list archive
  3. Message #04131

Re: wxDC zoom break through.

  Thread Previous • Date Previous • • Thread Next 
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
But if the runner is from Alaska, and needs to dress this way while *migrating*, this would be only a temporary situation before the real top end at time trials could be known. 


Dick

Follow ups

References

  Thread Previous • Date Previous • • Thread Next