| Thread Previous • Date Previous • Date Next • Thread Next |
emmedics4 wrote:
--- In kicad-devel@xxxxxxxxxxxxxxx, "Torsten Hüter" <torstenhtr@...> wrote:Yes, you're right, the additional cost is another library to maintain. However the bonus is, that it helps to accelerate the drawing speed - exactly because it was optimized for speed. AFAIK even antialiasing should work. It's well supported for Linux / Windows (mingw) / Mac OS X. I could imagine that for KiCad is a abstract graphics layer is created and different rendering engines are used as plugins (like for instance some emulators use). I'll play with it at the weekend.For what i know wxGC is only an interface to GDI+ on win , Core Graphics (Quartz 2D) on OSX or Cairo on Linux. I personally think that you couldn't have much more performance than wxGC, but i will be pleased to be wrong :) Let us know :) -- Marco
Here is an excerpt from http://www.wxdesigner-software.de/WoWoW30.html New 2D Drawing CodeAlthough a 2D drawing API has always been part of wxWidgets (using so-called device contexts such as a window or a bitmap and pens and brushes to draw into them, see wxDC <http://docs.wxwidgets.org/trunk/classwx_d_c.html>, wxPen <http://docs.wxwidgets.org/trunk/classwx_pen.html>, wxBrush <http://docs.wxwidgets.org/trunk/classwx_brush.html>), it has not changed much since its initial inception and so the code was completely reorganized using a single set of frontend classes and different backends which will make maintainance much easier without having to care for binary backwards compatibility and it also helped isolate a number of subtle platform differences. The old drawing API is good enough for many tasks and reflects the drawing capabilites of the 1990's but it didn't make use of advanced features such as transparency, anti-aliasing and free matrix transforms of modern 2D graphics systems such as GDI+ on Windows, Cairo on Linux (and elsewhere) and CoreGraphics on OS X. Therefore a completely new drawing API (the so called graphics contexts, see wxGraphicsContext <http://docs.wxwidgets.org/trunk/classwx_graphics_context.html>) was added to wxWidgets making use of modern drawing engines. This is complemented by a bitmap class with alpha channel support and fast raw access to the bitmap's internal data representation. Additionally the API of all existing GDI class constants was corrected so that wxMODERN becomes wxFONTFAMILY_MODERN, wxSOLID becomes wxBRUSHSTYLE_SOLID etc. and the reference counting system was streamlined and made identical on all platforms.
--------------------We are at a fork in the road, and the rate of travel down the "graphics API" road is not fast. So we have time to take a little tour down the most logical path, which is wxGraphicsContext, before we say it is a bad idea. Another thing to keep in mind with this metaphor is that roads can be improved. Bumps can be fixed, and con be tolerated for a period of time knowing that improvements are on the way.
Starting to push the vehicle will require volunteers, and it should not happen until after the pending release. I agree with Marco, that adding another library comes at a cost. We have yet to get hurt by wxGraphicsContext (because we are not using it to my knowledge) so that cost is currently unwarranted IMO. But if the wxGraphicsContext gets traveled on and becomes overly painful, we can revisit the fork in the road again.
Writing to wxGraphicsContext may bring up the whole issue of coordinate datatypes, int or double. I don't know the cost of doing conversions from int to double for every call. If expensive, we may want to switch to double coords at that time. However I doubt it is expensive, but I don't need to guess, we can measure it.
Talk will not as helpful as code. And what we need is a small tour before we commit the whole caravan to given path at the fork.
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
