kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #04159
wxDC break through update.
-
To:
kicad-devel@xxxxxxxxxxxxxxx
-
From:
Wayne Stambaugh <stambaughw@...>
-
Date:
Mon, 08 Feb 2010 13:17:05 -0500
-
User-agent:
Thunderbird 2.0.0.23 (Windows/20090812)
I just committed the wxDC update. To test out the wxDC coordinate
scaling and offsetting set the USE_WX_ZOOM build option to ON. To test
the wxGCDC rendering, set both USE_WX_ZOOM and USE_WX_GRAPHICS_CONTEXT
options to ON. At the moment wxGCDC is only usable for testing the
rendering speed on Linux. I had to set the draw mode to wxCOPY because
anything drawn in the wxOR and wxNOR draw mode doesn't show up on
PCBNew's black background. My guess is this has something to do with
the interaction between the drawing mode and alpha blending of wxGC on
GTK. The situation on windows is not as I had hoped. Apparently wxGC
on windows does not play nice with the coordinate manipulation in wxDC
so it renders nothing useful as it attempts to draw off of the screen
area. Obviously, there will need to be some additional work done to get
wxGCDC to render the same way wxDC currently renders across all
platforms. There is a noticeable speed difference on Linux. However,
it is not completely unusable. I also had some more time to take a
closer look at wxGraphicsContext over the weekend and I believe Dick is
correct about using the wxGC path and matrix classes as the correct way
to fully test wxGC. wxGraphicsPath appears to be a queue for drawing.
Once the drawing queue is filled, then wxGC only needs to get called
once to actually render to the device. My guess is that calling the
wxGC to draw each line, arc, circle, etc. creates the overhead that
slows wxGC. At least now we can use conditional compilation to replace
the current drawing code with wxDrawPath to see if that solves the wxGC
performance problem. Going forward, here is what I would like to see
happen:
1) Verify the wxDC coordinate scaling and offsetting works correctly.
Please build Kicad with USE_WX_ZOOM and test it thoroughly to find
anything I may have broken.
2) When (if?) this is adopted, remove the current Kicad coordinate
manipulation code, redundant scaled drawing functions in gr_basic.cpp,
and all of the ugly #ifdef USE_WX_ZOOM/#endif blocks.
3) Get wxDCGC to render correctly all platforms using the current
drawing scheme.
4) Start implementing wxGC based drawing to see if improves the
performance issues.
Would someone with OSX please try both of these changes to make sure I
didn't break anything.
Wayne
Follow ups