| Thread Previous • Date Previous • Date Next • Thread Next |
Wayne Stambaugh wrote:
Dick Hollenbeck wrote:Wayne Stambaugh wrote:Sounds fine to me. INSTALL_PAINTDC is not pretty IMO.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. WayneThe 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
| Thread Previous • Date Previous • Date Next • Thread Next |
