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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
