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 02:56:09

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/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.


> 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-developersPost to : kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developersMore help :https://help.launchpad.net/ListHelp

Offline

#2 Dec. 14, 2010 13:19:48

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

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


Hi Dick,

thanks, I'll add this patch.
I'm doing a lot of restructuring at the moment and write a small demo to test
the functions for rubberbanding - have not yet commited. I think I should be
ready this or next weekend with the rubberbanding test and then I'll commit and
open the repository for write access.

Bye ..
Torsten


> 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.
>
>
> > 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--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren:http://portal.gmx.net/de/go/demail_______________________________________________
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 Jan. 3, 2011 22:41:36

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 07:19 AM, "Torsten Hüter" wrote:
> Hi Dick,
>
> thanks, I'll add this patch.
> I'm doing a lot of restructuring at the moment and write a small demo to test
> the functions for rubberbanding - have not yet commited. I think I should be
> ready this or next weekend with the rubberbanding test and then I'll commit
> and open the repository for write access.
>
> Bye ..
> Torsten

Torsten,

Is this still on your to do list?

Some minor suggestions for improvements:

1)))))))))))))))))

Also, std::list should be changed to std::deque wherever it is being used.
std::list is too slow for several reasons:
a separate heap allocation must happen just to store the separate linked
list backbone noes, per content node.
That linkedlist node must store a pointer to real content node, slowing down
again the traversal, due to the dereferencing of the linked-list node pointer.
Heap allocation is by far the slowest issue. You have twice as many in a
std::list, I will use std::deque. Its ten minutes to change it.


2)))))))))))))))))

I am not a fan of BOOST_FOREACH. Some in this team are, I am not. It does
not provide enough value for the costs:

1) obscurity about what code it is actually generating.

2) longer compile times.

Suggest simply writing the 3 statements that the macro is replacing, so we
see what the compiler sees.


Again, I will need write access to this repo, if I am going to use it. I
was thinking of using it for a simple Sweet viewer. Of course I can always
make my own copy of the repo and make it public, thanks to your generosity
of contributing this code under the GPL. If you are too busy, let me know
and I will do these items myself.


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

#4 Jan. 3, 2011 23:43:13

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 01/03/2011 05:26 PM, "Torsten Hüter" wrote:
> Hi Dick,
>
>> Is this still on your to do list?
> Yes, of course, I just had not the time that I thought I would have and the
> example grows also bigger than expected ..
>
>> Some minor suggestions for improvements:
>>
>> 1)))))))))))))))))
>>
>> Also, std::list should be changed to std::deque wherever it is being used.
>> std::list is too slow for several reasons:
>> a separate heap allocation must happen just to store the separate linked
>> list backbone noes, per content node.
>> That linkedlist node must store a pointer to real content node, slowing
>> down
>> again the traversal, due to the dereferencing of the linked-list node
>> pointer.
>> Heap allocation is by far the slowest issue. You have twice as many in a
>> std::list, I will use std::deque. Its ten minutes to change it.
> Yes, I agree - this was just an initial choice - I've changed some types
> already to std::vector but the std::deque is also a good idea.
>
>> 2)))))))))))))))))
>>
>> I am not a fan of BOOST_FOREACH. Some in this team are, I am not. It does
>> not provide enough value for the costs:
>>
>> 1) obscurity about what code it is actually generating.
>>
>> 2) longer compile times.
>>
>> Suggest simply writing the 3 statements that the macro is replacing, so we
>> see what the compiler sees.
> The Eclipse CDT formatter has also a lot trouble with it. Good suggestion.
>
>> Again, I will need write access to this repo, if I am going to use it. I
>> was thinking of using it for a simple Sweet viewer. Of course I can
>> always
>> make my own copy of the repo and make it public, thanks to your generosity
>> of contributing this code under the GPL. If you are too busy, let me know
>> and I will do these items myself.
> Shouldn't take much time, I've changed only the directory structure a lot -
> I'll upload it in the next days.
>
> Bye ..
> Torsten

You da man!

std::vector is better than std::list. std::deque and std::vector are both
OK. The only difficulty with std::vector is if you hundreds of thousands of
points in a polyline, in which case the backbone array needs to be very
large. std::deque uses a segmented backbone, and could be slower than
std::vector for smaller numbers of points. So std::vector is fine if you
are already there.

Thank you.

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 Jan. 3, 2011 23:51:03

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

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


>> 2)))))))))))))))))
>>
>> I am not a fan of BOOST_FOREACH. Some in this team are, I am not. It does
>> not provide enough value for the costs:
>>
>> 1) obscurity about what code it is actually generating.
>>
>> 2) longer compile times.
>>
>> Suggest simply writing the 3 statements that the macro is replacing, so we
>> see what the compiler sees.
> The Eclipse CDT formatter has also a lot trouble with it. Good suggestion.

Another benefit there is I think you can then remove the findboost from the
CMakeLists.txt file.

I did a grep and it is the only boost dependency you have. (boost is fine,
but asking the user to tell you where it is comes at a cost to the user.
The benefit is not there for this.)

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

#6 Jan. 4, 2011 05:48:11

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

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


You have twice as many in a
>>> std::list, I will use std::deque. Its ten minutes to change it.
>> Yes, I agree - this was just an initial choice - I've changed some types
>> already to std::vector but the std::deque is also a good idea.
>>
> std::vector is better than std::list. std::deque and std::vector are both
> OK. The only difficulty with std::vector is if you hundreds of thousands of
> points in a polyline, in which case the backbone array needs to be very
> large. std::deque uses a segmented backbone, and could be slower than
> std::vector for smaller numbers of points.

Well even for relatively smaller numbers of POINTS, say 5000, std::deque is
faster than even std::vector. Here are the results of a test program I
wrote which uses push_back() against all 3 types of lists:

std::list, std::vector, and std::deque. Even at 5000 elements, deque wins
hands down. Try it at larger counts, test program attached.


$./test_lists

list duration: 828673

vector duration: 198271

deque duration: 123940

The times are in nanoseconds.

The test program is attached if you want to play with it.

std::deque needs more consideration than what I said in my last email. I
think the difference will be even more pronounced as the complexity of the
contained object becomes more pronounced, since std::vector must copy all
the objects to the expanded array as it grows. Makes me wonder if you
should loose the

virtual ~VECTOR2<T>

Just let anyone deriving from VECTOR2<> add in virtual destructors, you
don't need it at this level. It causes the virtual function table to be
copied and constructed, both of which cost time, for large numbers of points.


Dick/* Test the speed of insertion into 3 kinds of lists:
std::list, std::vector, std::deque
*/


#include <time.h>
#include <stdint.h>
#include <stdio.h>

#include <vector>
#include <deque>
#include <list>


unsigned GetRunningNSecs()
{
struct timespec now;

clock_gettime( CLOCK_MONOTONIC, &now );

uint64_t nsecs = now.tv_nsec + now.tv_sec * uint64_t(1000*1000*1000);

return unsigned( nsecs );
}


struct POINT
{
int x;
int y;
};


#define APPEND_COUNT 5000
//#define APPEND_COUNT 100000


int main( int argc, char** argv )
{
std::list<POINT> mylist;
std::vector<POINT> myvector;
std::deque<POINT> mydeque;

unsigned start = GetRunningNSecs();

for( int i=0; i<APPEND_COUNT; ++i )
{
mylist.push_back( POINT() );
}

printf( "\nlist duration: %u\n", GetRunningNSecs() - start );

start = GetRunningNSecs();

for( int i=0; i<APPEND_COUNT; ++i )
{
myvector.push_back( POINT() );
}

printf( "\nvector duration: %u\n", GetRunningNSecs() - start );

start = GetRunningNSecs();

for( int i=0; i<APPEND_COUNT; ++i )
{
mydeque.push_back( POINT() );
}

printf( "\ndeque duration: %u\n", GetRunningNSecs() - start );


return 0;
}_______________________________________________
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 Jan. 4, 2011 06:01:13

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

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


> It causes the virtual function table


pointer
> to be
> copied and constructed, both of which cost time, for large numbers of points.
>
>
> Dick

Its only another pointer, but its one you don't need in the object at this
level.




_______________________________________________
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 Jan. 5, 2011 23:48:43

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

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


Hi Dick,

> You have twice as many in a
> >>> std::list, I will use std::deque. Its ten minutes to change it.
> >> Yes, I agree - this was just an initial choice - I've changed some
> types already to std::vector but the std::deque is also a good idea.
> >>
> > std::vector is better than std::list. std::deque and std::vector are
> both
> > OK. The only difficulty with std::vector is if you hundreds of
> thousands of
> > points in a polyline, in which case the backbone array needs to be very
> > large. std::deque uses a segmented backbone, and could be slower than
> > std::vector for smaller numbers of points.

Yes, I've read as well, that at certain conditions the std::deque is faster.
Especially for our cases it should be the best solution; so I changed anything
to the deque.

> virtual ~VECTOR2<T>
>
> Just let anyone deriving from VECTOR2<> add in virtual destructors, you
> don't need it at this level. It causes the virtual function table to be
> copied and constructed, both of which cost time, for large numbers of
> points.

That's right; it was mainly a stub that Eclipse creates automatically. I've
commented it out; if it should be used later, the comment just needs to be
removed.

--

I had to apply some different changes for wxWidgets 2.8; now it should be run
there as well. The problem is that I've changed to the image backend of Cairo
and the blitting doesn't work like I'd like. So I'm using the code from
wxCairo; but it's much slower than a direct access with wxNativePixelData that
2.9 provides. I think it is even there room for impovements.
The rubberbanding demo is still bit stupid; at the moment it displays only a
QFN footprint (you can zoom with the mouse wheel and pan with the right mouse
button). I'll implement dragging of some objects later and seperate the classes
in different files.
There is still much in progress; also I have to add more documentation.

I've changed the branch owner to kicad-testing-committers. You should be able
now to commit changes.

Bye ..
Torsten

--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat!http://portal.gmx.net/de/go/dsl_______________________________________________
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 Jan. 6, 2011 14:19:01

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 01/05/2011 05:48 PM, "Torsten Hüter" wrote:
> Hi Dick,
>
>> You have twice as many in a
>>>>> std::list, I will use std::deque. Its ten minutes to change it.
>>>> Yes, I agree - this was just an initial choice - I've changed some
>> types already to std::vector but the std::deque is also a good idea.
>>> std::vector is better than std::list. std::deque and std::vector are
>> both
>>> OK. The only difficulty with std::vector is if you hundreds of
>> thousands of
>>> points in a polyline, in which case the backbone array needs to be very
>>> large. std::deque uses a segmented backbone, and could be slower than
>>> std::vector for smaller numbers of points.
> Yes, I've read as well, that at certain conditions the std::deque is faster.
> Especially for our cases it should be the best solution; so I changed
> anything to the deque.
>
>> virtual ~VECTOR2<T>
>>
>> Just let anyone deriving from VECTOR2<> add in virtual destructors, you
>> don't need it at this level. It causes the virtual function table to be
>> copied and constructed, both of which cost time, for large numbers of
>> points.
> That's right; it was mainly a stub that Eclipse creates automatically. I've
> commented it out; if it should be used later, the comment just needs to be
> removed.
>
> --
>
> I had to apply some different changes for wxWidgets 2.8; now it should be run
> there as well. The problem is that I've changed to the image backend of Cairo
> and the blitting doesn't work like I'd like. So I'm using the code from
> wxCairo; but it's much slower than a direct access with wxNativePixelData
> that 2.9 provides. I think it is even there room for impovements.
> The rubberbanding demo is still bit stupid; at the moment it displays only a
> QFN footprint (you can zoom with the mouse wheel and pan with the right mouse
> button). I'll implement dragging of some objects later and seperate the
> classes in different files.
> There is still much in progress; also I have to add more documentation.
>
> I've changed the branch owner to kicad-testing-committers. You should be able
> now to commit changes.
>
> Bye ..
> Torsten

Torsten,

Thank you *very* much. I appreciate your time and expertise.

For clarification, Are you saying that the implementation on top of 2.9 is
different and superior in a significant way?

Is the difference wxNativePixelData? And if so, is it a simple interface
that we simply conditionally compile into GAL? Obviously the stuff under
wxWidgets has not changed, and to a large extent you are simply doing a
bypass of wxWidgets from GAL to cairo or open gl, no?

Is the 2.8 "good enough" for GAL to make a decent impression on first time
observers? Or do you recommend 2.9? Or can be put a little of 2.9 into 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

#10 Jan. 6, 2011 15:43:11

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

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


On 1/6/2011 9:18 AM, Dick Hollenbeck wrote:
> On 01/05/2011 05:48 PM, "Torsten Hüter" wrote:
>> Hi Dick,
>>
>>> You have twice as many in a
>>>>>> std::list, I will use std::deque. Its ten minutes to change it.
>>>>> Yes, I agree - this was just an initial choice - I've changed some
>>> types already to std::vector but the std::deque is also a good idea.
>>>> std::vector is better than std::list. std::deque and std::vector are
>>> both
>>>> OK. The only difficulty with std::vector is if you hundreds of
>>> thousands of
>>>> points in a polyline, in which case the backbone array needs to be very
>>>> large. std::deque uses a segmented backbone, and could be slower than
>>>> std::vector for smaller numbers of points.
>> Yes, I've read as well, that at certain conditions the std::deque is faster.
>> Especially for our cases it should be the best solution; so I changed
>> anything to the deque.
>>
>>> virtual ~VECTOR2<T>
>>>
>>> Just let anyone deriving from VECTOR2<> add in virtual destructors, you
>>> don't need it at this level. It causes the virtual function table to be
>>> copied and constructed, both of which cost time, for large numbers of
>>> points.
>> That's right; it was mainly a stub that Eclipse creates automatically. I've
>> commented it out; if it should be used later, the comment just needs to be
>> removed.
>>
>> --
>>
>> I had to apply some different changes for wxWidgets 2.8; now it should be
>> run there as well. The problem is that I've changed to the image backend of
>> Cairo and the blitting doesn't work like I'd like. So I'm using the code
>> from wxCairo; but it's much slower than a direct access with
>> wxNativePixelData that 2.9 provides. I think it is even there room for
>> impovements.
>> The rubberbanding demo is still bit stupid; at the moment it displays only a
>> QFN footprint (you can zoom with the mouse wheel and pan with the right
>> mouse button). I'll implement dragging of some objects later and seperate
>> the classes in different files.
>> There is still much in progress; also I have to add more documentation.
>>
>> I've changed the branch owner to kicad-testing-committers. You should be
>> able now to commit changes.
>>
>> Bye ..
>> Torsten
>
> Torsten,
>
> Thank you *very* much. I appreciate your time and expertise.

Thanks Torsten for your efforts. I just built kicad-gal on Debian testing with
wxWidgets 2.8.10 and it looks great. The cairo rendering is really smooth. I
wonder if it will be fast enough for PCBNew? I had to fix CMakeList.txt in
order to make it build properly. Do you mind if I commit these changes? I
don't want to step on anything you are doing. When I get some time, I'm going
to try to get it to build on Windows using MinGW/MSYS.

Wayne

>
> For clarification, Are you saying that the implementation on top of 2.9 is
> different and superior in a significant way?
>
> Is the difference wxNativePixelData? And if so, is it a simple interface
> that we simply conditionally compile into GAL? Obviously the stuff under
> wxWidgets has not changed, and to a large extent you are simply doing a
> bypass of wxWidgets from GAL to cairo or open gl, no?
>
> Is the 2.8 "good enough" for GAL to make a decent impression on first time
> observers? Or do you recommend 2.9? Or can be put a little of 2.9 into the
> GAL?
>
> 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

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

Board footer

Moderator control

Enjoy the 17th 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