kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Vesa Solonen wrote:
> On Tue, 9 Jun 2009, Wayne Stambaugh wrote:
> 
>> Dick Hollenbeck wrote:
> 
>>> the user can install his own. wxFont on a wxGraphicsContext needs to be
>>> explored.
>> Agreed! Too many drawing object manipulations (fonts included) happen
>> outside of the device context. I'm guessing that before we can
>> effectively use wxFont, we are probably going to have to fix the the
>> drawing code to allow the device context to handle things like
>> coordinate scaling, offsetting, and clipping internally. If we need any
>> coordinate manipulation or specific drawing code that wxDC does not
>> provide, than we should derive our own DC from wxDC to provide any
>> missing or unique functionality rather than manipulate this outside of
>> the DC. I know this is off topic but piling more drawing code on top of
>> the current drawing code will just make Kicad harder to maintain.
> 
> Wayne, have you had time to research wxGC and if so what would you say 
> about it? I mean to draw attention that wxDC API may get depreciated by 
> more vector oriented design. Also could wxGraphicsPath be of value to 
> allow object caching?

Vesa,

I have only played around with wxGraphicsContext in the wxPython demo
and the wxWidgets drawing sample. Honestly, except for the floating
point coordinates and transforms there does not seem to be much
difference between the drawing primitives in wxDC. I haven't actually
look at the source code so I can't really comment on the implementation.
It certainly appears to render on the display much better than wxDC.
How well that will translate to other contexts (printing, plotting,
etc) remains to be seen.

> Others ponder thse problems too:
> http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/60842/focus=60851

I've seen these comments about rendering speed before. How much it will
effect Kicad is hard to say.

Wayne

> 
> -Vesa