kicad-developers team mailing list archive

[Manveru <manveru@...>]

--000325554d56b3820b047fa30bd6 Content-Type: text/plain; charset=UTF-8

2010/2/15 emmedics4 <marco.serantoni@...>

>
>
> --- In kicad-devel@xxxxxxxxxxxxxxx <kicad-devel%40yahoogroups.com>,
> Manveru <manveru@...> wrote:
> > > We are not using wxGraphicsContext yet. Your comments seem to be based
> > > on witnessing the combined (stacked) usage of both wxGCDC and
> > > wxGraphicsContext.
> > I only confirming well known fact - GDI+ is very slow.
>
> Manveru, as i show you is possible use CAIRO instead GDI+ on windows, just
> switching it on compiling time.
> I don't know why you are still doing a crusade against wxGC.
> What we have tested wxDCGC without use of Paths and the other instruments:
> is like drawing a line using as primitive the point.
>
> As we are thinking about rewrite the drawing code we are evaluating to pass
> to wxGC or still with wxDC.
> If we still with wxDC could be harder find the motivation to (re)write the
> code, the current one is doing more or less its dirty work and the work
> could have a lower priority.
> The step here is passing from bitmap graphics to vector graphics that is HW
> accelerable, i personally think that nowadays for a CAD that becomes a MUST.
>
>
> > All criticism - I cannot find good word about GDI+...
> We aren't talking about GDI+ but of wxGraphicsContext, you can wrap the
> library you want with that APIs, CAIRO is an example.
>
> If instead you prefer wxDC please tell us why explicitly and which are the
> benefits, persuade us, is a less resistance path and we could be motivated
> to pass through it.
>
>
I didn't see how may I switch to cairo. And I am not opponent of moving
KiCad further and I do not prefer wxDC. But from enything I read till now
wxGraphicsContext is strongly tied with GDI+ on Windows. I do not know
whether wxGraphicsContext is good or bad, but as far as I know it is not
accelerated from HW perspective.

Do not treat is as a crusade. I only feel not convinced that decision of
moving to wxGraphicsContext will speed up anything on Windows. I feel couple
people here would willingly abandon Windows support for achieving some
results.

But... there is always an option to write own
wxGraphicsRenderer<http://docs.wxwidgets.org/2.8.7/wx_wxgraphicsrenderer.html>with
support for OpenGL or DirectAnything (under Windows).

I am sure that KiCad need deep changes in its drawing core, and I (and I
think many others) appreciates Wayne's work in this area. From configuration
management perspective it would be nice to have separate branch for that,
and drive deep changes in drawing code in some separation from code on trunk
where only changes for closest releases should go directly. SVN supports
branches the same way it supports tags.

For me the subject is closed. I do not want to trigger any flame wars here
or anything else creating negative atmosphere.

-- 
Manveru
jabber: manveru@...
gg: 1624001
http://www.manveru.pl
 --000325554d56b3820b047fa30bd6 Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">2010/2/15 emmedics4 <span dir=3D"ltr">&l=
t;<a href=3D"mailto:marco.serantoni@...";>marco.serantoni@...</a=
>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px=
solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">













<div style=3D"background-color: rgb(255, 255, 255);">
<span>=C2=A0</span>


<div>
<div>


<div>
=20=20=20=20=20=20
=20=20=20=20=20=20
<p></p><div class=3D"im">--- In <a href=3D"mailto:kicad-devel%40yahoo=
groups.com" target=3D"_blank">kicad-devel@xxxxxxxxxxxxxxx</a>, Manveru &lt;=
manveru@...&gt; wrote:<br>
&gt; &gt; We are not using wxGraphicsContext yet. Your comments seem to be =
based<br>
&gt; &gt; on witnessing the combined (stacked) usage of both wxGCDC and<br>
&gt; &gt; wxGraphicsContext.<br>
&gt; I only confirming well known fact - GDI+ is very slow.<br>
<br></div>
Manveru, as i show you is possible use CAIRO instead GDI+ on windows, just =
switching it on compiling time.<br>
I don&#39;t know why you are still doing a crusade against wxGC.<br>
What we have tested wxDCGC without use of Paths and the other instruments: =
is like drawing a line using as primitive the point.<br>
<br>
As we are thinking about rewrite the drawing code we are evaluating to pass=
to wxGC or still with wxDC.<br>
If we still with wxDC could be harder find the motivation to (re)write the =
code, the current one is doing more or less its dirty work and the work cou=
ld have a lower priority.<br>
The step here is passing from bitmap graphics to vector graphics that is HW=
accelerable, i personally think that nowadays for a CAD that becomes a MUS=
T.<div class=3D"im"><br>
<br>
&gt; All criticism - I cannot find good word about GDI+...<br></div>
We aren&#39;t talking about GDI+ but of wxGraphicsContext, you can wrap the=
library you want with that APIs, CAIRO is an example.<br>
<br>
If instead you prefer wxDC please tell us why explicitly and which are the =
benefits, persuade us, is a less resistance path and we could be motivated =
to pass through it.<br><br></div></div></div></div></blockquote></div>
<br>I didn&#39;t see how may I switch to cairo. And I am not opponent of mo=
ving KiCad further and I do not prefer wxDC. But from enything I read till =
now wxGraphicsContext is strongly tied with GDI+ on Windows. I do not know =
whether wxGraphicsContext is good or bad, but as far as I know it is not ac=
celerated from HW perspective.<br>
<br>Do not treat is as a crusade. I only feel not convinced that decision o=
f moving to wxGraphicsContext will speed up anything on Windows. I feel cou=
ple people here <span class=3D"res_phr_translation">would willingly </span>=
abandon Windows support for achieving some results.<br>
<br>But... there is always an option to write <a href=3D"http://docs.wxwidg=
ets.org/2.8.7/wx_wxgraphicsrenderer.html">own wxGraphicsRenderer</a> with s=
upport for OpenGL or DirectAnything (under Windows).<br><br>I am sure that =
KiCad need deep changes in its drawing core, and I (and I think many others=
) appreciates Wayne&#39;s work in this area. From configuration management =
perspective it would be nice to have separate branch for that, and drive de=
ep changes in drawing code in some separation from code on trunk where only=
changes for closest releases should go directly. SVN supports branches the=
same way it supports tags.<br>
<br>For me the subject is closed. I do not want to trigger any flame wars h=
ere or anything else creating negative atmosphere.<br clear=3D"all"><br>-- =
<br>Manveru<br>jabber: <a href=3D"mailto:manveru@...";>manveru@manver=
u.pl</a><br>
=C2=A0 =C2=A0 gg: 1624001<br> =C2=A0 <a href=3D"http://www.manveru.pl";>htt=
p://www.manveru.pl</a><br>
 --000325554d56b3820b047fa30bd6--