Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » KiCAD
  • » [Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL) [RSS Feed]

#1 Dec. 14, 2010 09:22:50

Martijn K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


On Dec 14, 2010, at 2:55 AM, Dick Hollenbeck wrote:

> On 12/13/2010 01:48 PM, Dick Hollenbeck wrote:
>> Wayne and Torsten,
>>
>> Here is a patch that allows the GAL to compile and run on Ubuntu Lucid x86_64
>>
>> with *version wxWidgets 2.8.x*
>>
>> The key thing is the wxWidgets version. The repo seems to be dependent on
>> 2.9.
>>
>>
>> Moving forward, we're going to need write access to a branch holding this
>> stuff. I
>> think we should keep it a separate branch. Kicad's Cmake can be told to do
>> a checkout
>> later.
>
> If the *community* decision is to move forward with it. (Seems that could
> have been a
> point of mis-understanding.) I am only one voice, but I should get a good
> look at it
> over the Christmas break.

Great, for me an example (just like you planned) might show me the value of
Torstens' work. Not saying there isn't any, I am just not seeing it (my fault
really).

If I understand correctly you (DIck) are proposing to maintain 2 branches for a
while:
- Kicad as we know it
- Kicad Next Generation

If the next generation is as promising as is foreseen, then one day we
(Jean-Pierre) will just bless the next generation branch as the stable one.
Right ?

Thanks for all the effort people are putting into Kicad.

/Martijn

>
>> Thanks again to Torsten for what looks to be:
>>
>> 1) great work,
>> 2) conforming to the coding standards, and
>> 3) for patience in the supreme.
>>
>>
>> Regards,
>>
>>
>> Dick
>>
>
> _______________________________________________
> Mailing list:https://launchpad.net/~kicad-developers> Post to : kicad-develop***@*ists.launchpad.net
> Unsubscribe :https://launchpad.net/~kicad-developers> More help :https://help.launchpad.net/ListHelp_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#2 Dec. 14, 2010 15:28:21

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


On 12/14/2010 03:22 AM, Martijn Kuipers wrote:
> On Dec 14, 2010, at 2:55 AM, Dick Hollenbeck wrote:
>
>> On 12/13/2010 01:48 PM, Dick Hollenbeck wrote:
>>> Wayne and Torsten,
>>>
>>> Here is a patch that allows the GAL to compile and run on Ubuntu Lucid
>>> x86_64
>>>
>>> with *version wxWidgets 2.8.x*
>>>
>>> The key thing is the wxWidgets version. The repo seems to be dependent on
>>> 2.9.
>>>
>>>
>>> Moving forward, we're going to need write access to a branch holding this
>>> stuff. I
>>> think we should keep it a separate branch. Kicad's Cmake can be told to do
>>> a checkout
>>> later.
>> If the *community* decision is to move forward with it. (Seems that could
>> have been a
>> point of mis-understanding.) I am only one voice, but I should get a good
>> look at it
>> over the Christmas break.
> Great, for me an example (just like you planned) might show me the value of
> Torstens' work. Not saying there isn't any, I am just not seeing it (my fault
> really).

I had a cathartic moment this weekend when the BLIT operations under wxwidgets
on
linux flunked in the extreme.
I don't yet know what the better alternative is yet, just know we need one. For
gerbview, cairo and pixman are in my scope, and some research can be put into
techiques in gerbv and its graphical foundations, which I think are cairo and
pixman.

> If I understand correctly you (DIck) are proposing to maintain 2 branches for
> a while:
> - Kicad as we know it
> - Kicad Next Generation

I personally am only committing to a design, and to code only a new EESCHEMA
foundation. I won't live long enough to create a new Kicad, inclusive of
PCBNEW,
since I only have several hundred hours to donate each year. I hope it is not
just me
and Wayne working on this. Wayne is already on board to write critical
portions of
it, others are welcome.


Once the new foundation is poured, pieces of the old EESCHEMA can come over on
top of
the new foundation, one by one, and during that time we can get a look at each
piece
separately, to see if it is worth keeping or re-writing. Obviously the old
library
editor and manager will all go away. The parts list concept is not going to be
easy
to implement, and the chief struggle there will be providing a user friendly
interface
experience. That is why I wanted to do that very early, to prove the *UI* and
usability experience concepts early in the game.

The remote aspects of some of the LIB_SOURCEs don't currently seem as
difficult, and
they can be implemented incrementally over a long period of time, by any number
of
people at any time. The design enables that. Some of them will require
servers on
the back end, and much help is needed to write those, if they are to get done
at all.
Those servers are not cast in stone, other than they have to work with the
LIB_SOURCE
running on the client, which is in C++. But the servers themselves can be in
any
language, could be python, or an apache module, whatever.


> If the next generation is as promising as is foreseen, then one day we
> (Jean-Pierre) will just bless the next generation branch as the stable one.
> Right ?

Yes some time will be needed. The real EESCHEMA switch happens when folks
start using
it, and they will cast that vote when and if they find it superior.

Dick


> Thanks for all the effort people are putting into Kicad.
>
> /Martijn
>


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#3 Dec. 14, 2010 16:07:08

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


On 12/14/2010 09:38 AM, Lorenzo Marcantonio wrote:
> On Tue, 14 Dec 2010, Dick Hollenbeck wrote:
>
>> I had a cathartic moment this weekend when the BLIT operations under
>> wxwidgets on
>> linux flunked in the extreme.
>> I don't yet know what the better alternative is yet, just know we need one.
>> For
>> gerbview, cairo and pixman are in my scope, and some research can be put into
>> techiques in gerbv and its graphical foundations, which I think are cairo
>> and pixman.
> In my experience cairo is slower than anything I've seen (maybe even
> a Java2D would be faster).

Well you obviously did not recompile the latest gerbview with the patch that was
discussed Sunday night.

20 seconds to update 12 gerver layers or so, on a super fast computer.

cairo is NOT the slowest. Besides, current testing should speak louder than
past
experiences. I don't have an opinion yet on what is best for us. I just KNOW
it aint
what we are using.


> Look at gerbv in cairo mode to get an idea.
> pixman looks more promising but I've no experience on it.
>


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#4 Dec. 14, 2010 17:00:57

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


>> If the next generation is as promising as is foreseen, then one day we
>> (Jean-Pierre) will just bless the next generation branch as the stable one.
>> Right ?
> Yes some time will be needed. The real EESCHEMA switch happens when folks
> start using
> it, and they will cast that vote when and if they find it superior.

More important than Jean-Pierre's blessing, is his help. :)

The user's give the blessings.

> Dick
>


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#5 Dec. 14, 2010 17:35:23

jean-pierre c.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


Le 14/12/2010 17:06, Dick Hollenbeck a écrit :On 12/14/2010 09:38 AM, Lorenzo Marcantonio wrote:On Tue, 14 Dec 2010, Dick Hollenbeck wrote:I had a cathartic moment this weekend when the BLIT operations under wxwidgets
on
linux flunked in the extreme.
I don't yet know what the better alternative is yet, just know we need one. For
gerbview, cairo and pixman are in my scope, and some research can be put into
techiques in gerbv and its graphical foundations, which I think are cairo and
pixman.In my experience cairo is slower than anything I've seen (maybe even
a Java2D would be faster).Well you obviously did not recompile the latest gerbview with the patch that was
discussed Sunday night.

20 seconds to update 12 gerver layers or so, on a super fast computer.

cairo is NOT the slowest. Besides, current testing should speak louder than
past
experiences. I don't have an opinion yet on what is best for us. I just KNOW
it aint
what we are using.Look at gerbv in cairo mode to get an idea.
pixman looks more promising but I've no experience on it.For info: I spent some hours to test latest Gerbview, under Linux Ubuntu 10.10
, Windows XP and Vista.
I used a 10 layers very large board (9500 pads/vias, 27000 track segments, a
lot of copper areas)
on my computer (a very common and low cost PC with a basic graphic card)with a
single 1200x1000 pixels monitor.
I do not have any speed issues:
The new Gerbview is faster than the old version (at least as fast as Gerbv on
my computer).
The copy mode is roughly as fast as the or mode.
When Gerbview is full screen, it takes about 1 second to redraw the screen
(less than pcbnew to redraw the board).

So "20 seconds to update 12 gerver layers or so, on a super fast computer"
could be due to an other problem,
even with monitor that have more pixels than mine.

Having said this, I think if you are motivated to work on a new graphic
alternative using the experimental Torsten's work,
this is a *very good* news.

I do not know if cairo or an other tool is faster or not.
The answer will come from tests with very large boards on a lot of different
computers and OS.

But we can find a lot of enhancements (anti aliasing, better and more powerful
graphic primitives ...)
One of most important issues with the current wxDC implementation is the fact
one cannot have a scaling factor for graphic texts.
This is the main reason why Eeschema does not use usual fonts.

Cairo is a candidate, but have also a look to sfml2:
Developers are actively working on it.
It is multi platform.
It use currently cmake.
It is small.
It could be an other serious candidate.


--
Jean-Pierre CHARRAS


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#6 Dec. 14, 2010 17:55:22

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


On 12/14/2010 11:34 AM, jean-pierre charras wrote:
> Le 14/12/2010 17:06, Dick Hollenbeck a écrit :
>> On 12/14/2010 09:38 AM, Lorenzo Marcantonio wrote:
>>> On Tue, 14 Dec 2010, Dick Hollenbeck wrote:
>>>
>>>> I had a cathartic moment this weekend when the BLIT operations under
>>>> wxwidgets on
>>>> linux flunked in the extreme.
>>>> I don't yet know what the better alternative is yet, just know we need
>>>> one. For
>>>> gerbview, cairo and pixman are in my scope, and some research can be put
>>>> into
>>>> techiques in gerbv and its graphical foundations, which I think are cairo
>>>> and pixman.
>>> In my experience cairo is slower than anything I've seen (maybe even
>>> a Java2D would be faster).
>> Well you obviously did not recompile the latest gerbview with the patch that
>> was
>> discussed Sunday night.
>>
>> 20 seconds to update 12 gerver layers or so, on a super fast computer.
>>
>> cairo is NOT the slowest. Besides, current testing should speak louder than
>> past
>> experiences. I don't have an opinion yet on what is best for us. I just
>> KNOW it aint
>> what we are using.
>>
>>
>>> Look at gerbv in cairo mode to get an idea.
>>> pixman looks more promising but I've no experience on it.
>>>
> For info: I spent some hours to test latest Gerbview, under Linux Ubuntu
> 10.10 , Windows XP and Vista.
> I used a 10 layers very large board (9500 pads/vias, 27000 track segments, a
> lot of copper areas)
> on my computer (a very common and low cost PC with a basic graphic card)with
> a single 1200x1000 pixels monitor.
> I do not have any speed issues:
> The new Gerbview is faster than the old version (at least as fast as Gerbv on
> my computer).
> The copy mode is roughly as fast as the or mode.
> When Gerbview is full screen, it takes about 1 second to redraw the screen
> (less than pcbnew to redraw the board).
>
> So "20 seconds to update 12 gerver layers or so, on a super fast computer"
> could be due to an other problem,
> even with monitor that have more pixels than mine.
>
> Having said this, I think if you are motivated to work on a new graphic
> alternative using the experimental Torsten's work,
> this is a *very good* news.
>
> I do not know if cairo or an other tool is faster or not.
> The answer will come from tests with very large boards on a lot of different
> computers and OS.
>
> But we can find a lot of enhancements (anti aliasing, better and more
> powerful graphic primitives ...)
> One of most important issues with the current wxDC implementation is the fact
> one cannot have a scaling factor for graphic texts.
> This is the main reason why Eeschema does not use usual fonts.
>
> Cairo is a candidate, but have also a look to sfml2:
> Developers are actively working on it.
> It is multi platform.
> It use currently cmake.
> It is small.
> It could be an other serious candidate.

Jean-Pierre,

Thanks for the discussion on gerbview.

1920 x 1200 = 2304000 pixels
--------------------------------- = 1.92

1200 x 1000 = 1200000 pixel


Yes, it seems you are correct, the area difference is no explanation for this
large
difference in blit "mask with AND" mode.

So the question is, how many users will find themselves with the same problem?
Hard
to answer if we don't know the reason for the problem.

gerbv is MUCH faster on my computer than the latest gerbview using "mask with
AND".
However, using blit OR mode, gerbview is faster than gerbv.

If we can get that button in there to toggle the mode, perhaps we can simply
postpone
solving the blit "mask with AND" question.

=============================================

Also, thanks for your thoughts on the graphics subsystem.

Actually writing some bit of new code for Torsten's API will provide us with a
lot of
observations. If the API is sound, most anything can be tucked underneath it.

After all, it is a GAL.

As far as speed goes, we may not get a good read on the speed until something
more
demanding is done with it, like a gerbview or pcbnew. EESCHEMA would ask
relatively
little of the GAL.

Dick



_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#7 Dec. 14, 2010 17:59:21

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


> Thanks for the discussion on gerbview.
>
> 1920 x 1200 = 2304000 pixels
> --------------------------------- = 1.92
>
> 1200 x 1000 = 1200000 pixel
>
>
> Yes, it seems you are correct, the area difference is no explanation for this
> large
> difference in blit "mask with AND" mode.


Well on second thought, it is not O(screen area).

Screen area could be the entire reason.

I will try it with a reduced resolution setting soon.

Dick


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#8 Dec. 14, 2010 18:41:24

Vesa S.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


On Tue, 14 Dec 2010, jean-pierre charras wrote:I used a 10 layers very large board (9500 pads/vias, 27000 track segments, alot of copper areas)on my computer (a very common and low cost PC with a basic graphic card)witha single 1200x1000 pixels monitor.Blitting is very fast on systems with shared graphics memory, but anythingmore demanding is less than very fast. Systems like Intel 965 are verygood up to a certain point and that is the point when they choke on thecount of Gl primitives. "lspci | grep VGA" and "glxinfo -l" will bringmuch insight to the problem when hitting a hardware limit. Nvidia blob hassome interesting feature that is very good performance in immediate modeOpenGl. Maybe they do some command queueing and on the fly restructuringto get there, but that makes even crappy programs perform well. Nvidia 2Dperformance seems to be nothing to brag about though. All my hw is fewyears old dual cores with q965 chipsets that didn't live up to theirpromises with Vista and one r300 discrete graphics machine is ocassionallytested too.-Vesa

_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#9 Dec. 15, 2010 07:15:28

jean-pierre c.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


Le 14/12/2010 18:59, Dick Hollenbeck a écrit :Thanks for the discussion on gerbview.

1920 x 1200 = 2304000 pixels
--------------------------------- = 1.92

1200 x 1000 = 1200000 pixel


Yes, it seems you are correct, the area difference is no explanation for this
large
difference in blit "mask with AND" mode.Well on second thought, it is not O(screen area).

Screen area could be the entire reason.

I will try it with a reduced resolution setting soon.

DickI forgot:

If you are compiling with option USE_WX_ZOOM = ON, the patch has a bug in
BOARD::Draw.
line
aPanel->DrawBackGround( &screenDC );
must be
aPanel->DoPrepareDC(screenDC);
aPanel->DrawBackGround( &screenDC );

Otherwise, if the grid display option is ON, the grid is always drawn,
regardless the grid size in pixels,because in the current device context, the user scale is set to 1.0, and testing to see if the grid size in pixel is more than 10pixels fails.For zoom values of 16 and more, the grid drawing routine is therefore very long and can easily explain 20 seconds to redraw thescreen.Roughly, the grid routine try to draw the grid on a screen size of zoom *
screen_size_x * zoom * screen_size_y.
If the grid size is low and zoom value hight, it takes a while.

(Can be avoid if you switch the grid display OFF)


--
Jean-Pierre CHARRAS


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#10 Dec. 15, 2010 22:17:21

Dick H.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL)


On 12/15/2010 01:15 AM, jean-pierre charras wrote:
> Le 14/12/2010 18:59, Dick Hollenbeck a écrit :
>>> Thanks for the discussion on gerbview.
>>>
>>> 1920 x 1200 = 2304000 pixels
>>> --------------------------------- = 1.92
>>>
>>> 1200 x 1000 = 1200000 pixel
>>>
>>>
>>> Yes, it seems you are correct, the area difference is no explanation for
>>> this large
>>> difference in blit "mask with AND" mode.
>>
>> Well on second thought, it is not O(screen area).
>>
>> Screen area could be the entire reason.
>>
>> I will try it with a reduced resolution setting soon.
>>
>> Dick
>>
> I forgot:
>
> If you are compiling with option USE_WX_ZOOM = ON, the patch has a bug in
> BOARD::Draw.
> line
> aPanel->DrawBackGround( &screenDC );
> must be
> aPanel->DoPrepareDC(screenDC);
> aPanel->DrawBackGround( &screenDC );
>
> Otherwise, if the grid display option is ON, the grid is always drawn,
> regardless the grid size in pixels,
> because in the current device context, the user scale is set to 1.0, and
> testing to see if the grid size in pixel is more than 10
> pixels fails.
>
> For zoom values of 16 and more, the grid drawing routine is therefore very
> long and can easily explain 20 seconds to redraw the
> screen.
> Roughly, the grid routine try to draw the grid on a screen size of zoom *
> screen_size_x * zoom * screen_size_y.
> If the grid size is low and zoom value hight, it takes a while.
>
> (Can be avoid if you switch the grid display OFF)

Jean-Pierre,

I have 15 *.pho files associated with the board I had sent you for debugging the
zones. Fifteen *.pho layers. That screen redraws in 1.8 seconds using the
"bitmask
with COPY" mode.
On a full screen.

*The twenty seconds was a bad report, sorry.*

I think I loaded the gerbers on the command line with "ks*.pho" and ended up
with 30
gerbers, since there were two root filename sets, say ks1*.pho and ks2*.pho.
My bad.
But it was never 20 seconds, just feld like it, and mostly because the loading
of the
gerbers redraws the screen after each individual layer.

In the OR mode, it is faster.

If I scrink the screen, it gets faster, goes down to 0.7 seconds or so,
approximately
proportional to screen area. The grid had not much effect that I could tell.

I think the 1.8 seconds is tolerable for now. And the faster OR mode even more
so.

I really like the look of the "bitmask with COPY" mode.

It would be nice to have both modes.

Lastly until I buffered using screenDC, I had been getting screen flashing
using the
"bitmap with COPY" mode. So I think we need to keep that, or something like it.


GetBoard()->Draw( DrawPanel, DC,
GR_COPY, // this needs to be GR_COPY or GR_OR,
set
from a toggle button.
wxPoint( 0, 0 ) );


That argument GR_COPY, if it could be button toggled to GR_OR, with the other
TODO
items I mentioned when I emailed the patch, would probably make for an
excellent step
forward for this tool.

Thanks,

Dick


_______________________________________________
Mailing list:https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

  • Root
  • » KiCAD
  • » [Kicad-developers] [PATCH] wxWidgets 2.8 under Graphics Abstraction Layer Lib (GAL) [RSS Feed]

Board footer

Moderator control

Enjoy the 24th of August
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support