[Kicad-developers] Newstroke font truetype version
Hello, I am just wondering - is there a .ttf version of the newstroke font used in KiCad available? Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] The KiCad GAL new release
Ladies and Gentlemen, Today you can see another release of the KiCad GAL, that can be considered as a release candidate 1. It may still contain some bugs and is still missing some minor features, but the main purpose of the release is to make some tests and receive a feedback. I will be grateful for every opinion that I receive. The way of compilation changed a little, but now it is more like an usual KiCad build (I removed the KICAD_GAL switch from CMake): bzr branch lp:~cern-kicad/kicad/kicad-gal mkdir build cd build cmake -DKICAD_TESTING_VERSION=ON -DCMAKE_BUILD_TYPE=RELEASE .. make I am asking you to build the release version not without a reason - on my PC the debug version is about 4-5 times slower. If you want to test it under Windows, you may try to cross compile it using the recipe at http://www.ohwr.org/documents/251 (or I can put the binary somewhere on the web). In the meantime I am going to work with Kerusey Karyu to make it possible to build it using a modified version of Brian's KiCad WinBuilder (https://launchpad.net/kicad-winbuilder) under Windows. Similarly to the previous release - you may switch the backends anytime, using the View menu or hot keys Alt+F9 (standard KiCad rendering), Alt+F11 (OpenGL with shaders) and Alt+F12 (Cairo). The main changes include an introduction of shaders to the OpenGL GAL backend. The shaders are compliant with GLSL 1.20 which is 7 years old right now, so I guess any even not-so-recent GPU can cope with that (including my notebook's integrated Intel GPU with open source drivers under Linux). The second change is that we got rid of most of the deprecated GL calls, replacing them with vertex buffer objects. At the same time shaders were introduced, both combined resulted in a huge performance boost. I invite you to take it for a test drive with the most complex PCBs you have. I was testbenching it with a 12 copper layers PCB that you can find at http://www.ohwr.org/attachments/download/2187/wrs.kicad_pcb (please do not pay attention to the wrongly placed labels, the plugin we used to import the board is incomplete). The Cairo backend obviously is not that fast, but its main purpose is to generate documents using vectorized graphics (eg. pdfs). The smaller changes compared to the previous release are: - dynamic display of netnames on tracks pads - switching display modes for zones - high contrast mode - zoom grid settings are working At the same time that I am going to remove bugs that you may find (hopefully not), I would like to add some smaller features: - obeying the display settings for showing netnames (tracks pads) - 1px width lines for outline drawing Thanks in advance for your feedback. Kind regards, Orson, CERN ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
Hi Alex, Thank you for reporting the bug, the fix is already included in the repository and your PCB file made the fixing process as easy as it could be. By the way, as you have already run some tests - would you share some thoughts? I am also quite interested in what kind of system (OS GPU, proprietary/open source drivers in case of Linux) you are using, so I could know that this type of setup works with GAL. Kind regards, Orson On 07/09/2013 06:07 AM, Alex G. wrote: On 07/08/2013 02:35 PM, Maciej Sumiński wrote: I invite you to take it for a test drive with the most complex PCBs you have. Hi Me again. This is my most complex PCB: http://g-tech.no-ip.org/~mrnuke/kicad_gal_test/vultureprog.brd It's not as impressive as your FPGA oscilloscope (I assume that's what it is), but it was able to uncover a little bug. Observe the PRELIMINARY DESIGN text on the front silkscreen. When you switch from the default rendering mode to any of the new modes, those two words display overlapped. Hope this helps, Alex ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
On 07/09/2013 11:49 AM, Alex G. wrote: Right now I can't seem to be able to lay tracks or do anything useful with the non-default mode. There isn't much I can test unless I lay down an actual PCB. Yes, it is still not editable version, I should mention this in the release notes. Editing will be possible after implementation of the tool framework (http://www.ohwr.org/projects/cern-kicad/wiki/WorkPackages#5-Tool-framework), which is the next goal after the GAL. I don't like that OpenGL modes do not have antialiasing. I've tried to force my driver to do antialiasing, but does not work for pcbnew (works in the #D viewer though). Cairo made has AA, but it's extremely slow, even with my little board. I'd like to see the rendering quality of cairo with the performance of OpenGL. That would be awesome. I will put it on the to-do list, especially that I can recall having it working some time ago. And I also consider this as a nice feature to have. Also, I have a little issue with the way zone edges are rendered. If you look on the leftmost connector, between pins PB4 and PA5. To the left of those, the ground plane ends, but the way it is rendered gives the illusion that it shorts with the PA6 track. Does this make sense? In fact - not much, it is going to be fixed together with outline modes, when a single line will have a width of 1px without depending on the scale of the view. Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
Hi Camille, Thanks for the tests and the bug report. On 07/13/2013 02:04 PM, Camille Delbegue wrote: I tested GAL with all demo board in the repository and netnames on pads are visible only with 3 boards. It woks only with: - flat_hierarchy.kicad_pcb - interf_u.kicad_pcb - pic_programmer.kicad_pcb This seems strange to me - I have just tried out all of board included in the demo folder and everything was fine. Netnames show up, when the zoom is big enough - maybe try zooming even more? The second issue is about high contrast mode. The netnames are draw under the highlighted layer (see screenshot of comlex_hierarchy.kicad_pcb). I have just observed that too, I will fix it soon. There is also a transparency problem with the OpenGL backend and netnames, netnames under tracks are not draw (see screenshot). It is not very clear to me - could you describe the problem with more details? Is it about the case shown on the picture in the attachment? If yes - then it was done on purpose. Netnames are shown directly over tracks, so there are no situations when there is a track, a zone over the track and a netname is shown on the zone. Also, having semitransparent netnames blending into each other makes them hard to read, I think it is better when one is covered by another than when they are mixed up. Kind regards, Orson attachment: cross_tracks.png___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
On 07/16/2013 12:03 PM, Camille Delbegue wrote: This seems strange to me too. This problem apears only with demo boards and not with my projects (6 boards). I try to zoom more but nothing change, netnames show on tracks but not on pads. Is there someone who experiment the same issue ? I have changed a bit organization of layers - maybe it will solve the problem, as I could not reproduce the bug to test if it is already gone. The second issue is about high contrast mode. The netnames are draw under the highlighted layer (see screenshot of comlex_hierarchy.kicad_pcb). I have just observed that too, I will fix it soon. The fixed version should be already in the repository. I remark some difference between Cairo backend and OpenGL backend. With OpenGL backend, netnames are covered by the other tracks or copper zone, whereas with Cairo, netnames are mixed up with over item. I attached pictures of the different backends results. Thanks for clarifying that, it was hard for me spot the difference. It should be also fixed too. By the way - I have also noticed that there were some layers missing in the high contrast mode (eg. pads vias). Now it looks like I really desired. Kind regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
On 07/19/2013 11:08 PM, Camille Delbegue wrote: It is better but not perfect. Now netnames show on multilayers pads and bottom pads but not on top pads. The two other issues are resolved. I have managed to recreate the bug. The strange thing is - even within the same machine, but on two different Linux operating systems (ie. exactly the same hardware, but different kernels, graphics driver versions and libraries) it may occur or not. Could you do me a favor and try it out with the proprietary drivers too? I use Intel open source drivers, which does not have a proprietary version, so I cannot test it this way. Anyway, I will try to find a workaround, but it may take some time, as right now I am focused on a different task. Kind regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
Hi Camille, On 07/19/2013 11:08 PM, Camille Delbegue wrote: It is better but not perfect. Now netnames show on multilayers pads and bottom pads but not on top pads. Could you test the current version? I have managed to fix the problem on my machine, so hopefully it should be fine with yours too. BTW: can you also try Cairo backend and test if it is still fine? Which version of Cairo do you use? Kind regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The KiCad GAL new release
On 07/29/2013 04:11 PM, Camille Delbegue wrote: Cairo backend doesn't work properly, it is like if the old buffers are not deleted. But sometimes the buffer is correctly refreshed. I attached a picture resulting of a zoom out action. I also encountered this issue with rev 4211 Could you check it again? It seems to be fine now, using the configuration that gave me the same erroneous Cairo output, so it should work on your platform too. Hopefully I have finally got rid of all the display issues. Still, if you find one - do not hesitate to inform me, you are a good tester. Kind regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] kicad-gal minor fixes
Hi Camille, On 08/05/2013 05:25 PM, Camille Delbegue wrote: This patch remove a Clang warning and add a missing dependency to boost in cmake file. Thanks for the patch, it is already applied (rev 4229). Kind regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] KiCad Winbuilder for the GAL branch
Just a short note - for those who have been missing it, there is a modification of Brian's Winbuilder script that works with the GAL branch: http://orson.net.pl/kicad-winbuilder-gal.zip Special thanks goes to Brian Sidebotham and Kerusey Karyu who helped me with the script. The next step is to prepare a Mac OS build, hopefully it will not take too much time. Kind regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad Winbuilder for the GAL branch
I do not want to make it a long discussion, but as I based on your fixes I felt obliged to say thank you for that. Who knows? Maybe I would not make it at all without them.. Kind regards, Orson On 08/12/2013 03:02 PM, Kerusey Karyu wrote: FYI: I can't feel as one of the founders of GAL WinBuilder because my contribution was quite marginal. I was just a stone that started an avalanche. Regards Kerusey Karyu ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] KiCad GAL on Mac OS X
Thanks to the KiCad OSX Builder team (credits go to Miguel Angel Pajo Pelayo, Felix Morgner and Adam Wolf), now we are able to support KiCad GAL on the Mac OS X too. That means, that all of the three major platforms are already covered. To those who use Macs - I invite you to build (http://www.ohwr.org/documents/293) and/or run (http://orson.net.pl/pcbnew-osx_27082013.zip) and test, test, test! Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Experiments and considerations for more layer
On 09/05/2013 10:55 PM, Lorenzo Marcantonio wrote: On Thu, Sep 05, 2013 at 02:14:03PM -0500, Dick Hollenbeck wrote: You are correct about the model being somewhat exposed. But the model is working nicely everywhere else, and it is fast. I could argue about the 'fast' thing. The indexed by layer structure IMHO is very promising (the bounding box rtree would be the next logical step). Of course some kind of global enumeration (call it dlist, or thru the collectors) need to be maintained anyway. BTW: This is the way how it is done in the VIEW class in the GAL - items are held using R-trees, which are created for every layer. It was also necessary to know which layers are occupied by a single item, so there is ViewGetLayers() function that returns an int[] containing layer numbers for the given item. The layer numbers are computed during the function call (ie. ViewGetLayers() is overridden in derived classes, so eg. TRACK may return a different set of layers than SEGVIA), but I lean toward using std::bitset. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Experiments and considerations for more layer
On 09/06/2013 09:26 AM, Lorenzo Marcantonio wrote: On Fri, Sep 06, 2013 at 08:53:12AM +0200, Maciej Sumiński wrote: Other than being a technique listen even in '80 computer graphics books, I suppose that's needed also for 1) culling the primitives using the rtree and 2) sorting the draw operation by layers to achieve correct blending. IIRC even using the z-buffer and checking blending only works correcly when drawing from bottom up, in opengl (and probably everywhere else too) About culling - you are right, only things that are visible in the current viewport are drawn. The order of drawing is a matter only for the Cairo backend, in OpenGL it works fine without such requirement. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Interesting DLL Hell with SSL
Hi Brian, In fact it looks very strange.. I am just wondering - wouldn't it be easier to link OpenSSL as a static library? It may require a rebuild in the KiCad-Winbuilder, but then you will not have to care about stuff that users keep in Windows directory. Regards, Orson On 10/04/2013 12:28 AM, Brian Sidebotham wrote: This project: http://tibcoadmin.com/tibco/activematrix-businessworks/problem-with-libeay32-dll-and-ssleay32-dll/ has seen this behaviour too, and also concludes that the PATH is ignored in the search for the library. Their solution is to copy their DLL and overwrite the one in SysWOW64! lol. What a mess. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] MASM Boost dependency on Windows
On 10/15/2013 03:33 PM, Lorenzo Marcantonio wrote: On Tue, Oct 15, 2013 at 02:18:19PM +0100, Brian Sidebotham wrote: As Dick says, this completely breaks cross-compilation of Boost. Well, can't say it is a good thing... as a workaround maybe supplying precompiled (preassembled!) object for that couple of file could be useful, too. I am just wondering - don't those files included in the CERN branch (http://bazaar.launchpad.net/~cern-kicad/kicad/testing/files/head:/common/system/) solve the problem? If no - what is wrong with them, maybe we can introduce some modifications? I was able to build the KiCad using these files on every supported platform (actually the tool framework and the push and shove router depends on them). Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Ratsnest for the GAL
Hi all, We need a ratsnest that works with the GAL, therefore I present to you the blueprints for that part: https://blueprints.launchpad.net/kicad/+spec/ratsnest-gal I have seen many great ideas appearing on the mailing list, that's why everyone is welcome to share thoughts. I believe it may lead to a better/faster/more functional implementation in the end. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Ratsnest for the GAL
On 10/16/2013 03:54 PM, Carl Poirier wrote: FYI, in step 4 of the algorithm, I believe you wanted to refer to step 3: *4. Remove edges with zero weight.* The last step is to remove zero weight edges (as they are already connected). The remaining edges make the ratsnest. This step could be integrated with the step 3, as 0-weight edges could be filtered Carl You are right, thanks for catching this. Good that you can find careful readers here. It's already fixed. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Ratsnest for the GAL
On 10/16/2013 02:59 PM, Dick Hollenbeck wrote: On Oct 16, 2013 7:53 AM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: Looks promising, and super job on the presentation. Once you have it working, give some thought to using a special purpose allocator for the elements of your container. A memory pool scheme, anchored on the container, might pay dividends if it removes the size test for element allocations. If you want the pool anchored on the container, then overloading operator new is not best, but rather have a container function do the allocations of its elements (from a pool it owns.) Invariably this means having an in place new operator for the element, not a normal new operator overload. Such anchoring of pool in container is a separate decision from deciding to use a fixed block allocator at all. The fixed block allocator will be worth it regardless of where the pool lives. If you have to move elements from one container to another, then anchoring the pool on the container is not appropriate. But you could then have a class that held all your containers and a pool common to those containers. I bring this up because when instantiating hundreds of thousands of elements, memory heap calls can be the bottleneck. Thanks for the suggestion - I like the idea. I have briefly read the boost::pool project page and initially it seems to be an easy solution to the problem. Especially that nodes are very likely going to be POD structures with fixed size. I guess it is already included in C++11 as the emplace() function that is available for many std containers. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Partial fix for Mac OS X pcbnew text edit crashes; any suggestions to complete the fix?
Hi Andrew, On 10/24/2013 02:27 PM, Andrew Plumb wrote: Aside: I've been using the CERN https://github.com/mangelajo/KicadOSXBuilder scripts to semi-automate my Mac OS X bundle building. Very handy! I feel obliged to say that all the credits for the KicadOSXBuilder should go to Miguel Angel, as he is the main author of the script. Indeed it is very handy, it was a quick way for me to run Kicad on Mac OS even if it was my first experience with this machine. From our side it was just really a minor modification to run it with our branch. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Redraw issue in modedit and Modview with GAL
Thank you for the report, I am going to fix it now. Regards, Orson On 11/01/2013 12:10 PM, jp charras wrote: Modedit and Modview have a strange behavior when the main canvas is redrawn. Something is drawn in the upper left corner of the screen (i.e. form the center of the main canvas to the left corner of the main window client area. Could be related to the fact the logical origin and therefore the draw offset to draw items is not the same for the board editor and for Modview and Modedit: in board editor, the draw origin is the upper left corner of the page, and in Modview and Modedit, the draw origin is the center of the page (because for footprints, the origin of coordinates is usually the center of the footprint). ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Redraw issue in modedit and Modview with GAL
On 11/01/2013 01:50 PM, jp charras wrote: Le 01/11/2013 13:16, Maciej Sumiński a écrit : On 11/01/2013 12:10 PM, jp charras wrote: Modedit and Modview have a strange behavior when the main canvas is redrawn. Something is drawn in the upper left corner of the screen (i.e. form the center of the main canvas to the left corner of the main window client area. Could be related to the fact the logical origin and therefore the draw offset to draw items is not the same for the board editor and for Modview and Modedit: in board editor, the draw origin is the upper left corner of the page, and in Modview and Modedit, the draw origin is the center of the page (because for footprints, the origin of coordinates is usually the center of the footprint). The attached patch should solve the problem. Regards, Orson It works. Thanks, Orson, you are fast. I need to be - I really want to attract people with GAL, not discourage them. Finally the code is widely tested, so there is an opportunity to fix bugs that I could not discover myself. I tested wxWidgets 3.0.RC2 under Linux. When switching canvas to OpenGL, the zoom change from mouse wheel does not work (I also have other issues with zoom change from mouse wheel under Windows and wxWidgets 3.0.RC2, but not specific to OpenGl) I have noticed that too, but it has lower priority on my list, as there are probably very few people who build wxWidgets themselves (especially the bleeding edge version). But I will try to fix it as soon as the time allows. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GAL layers
On 11/01/2013 01:48 PM, Lorenzo Marcantonio wrote: OK, I'm trying to follow the road to isolate GAL layers and pcbnew layers. Let's see if it can work: - pcbnew still uses LAYER_NUM (for layers) and PCB_VISIBLE (for other stuff) - GAL *doesn't* use LAYER_NUM, because a) it wouldn't work anyway with eeschema in future and b) it extends the range to contain PCB_VISIBLE values (offset at the end of the layers) - PCB_VISIBLE was extended to handle more things, like the overlay and the netnames; at the moment I don't see problems with that. I added a GAL_LAYER_NUM type (another enum) to be used in the GAL/View stuff. There was already the ITEM_GAL_LAYER macro (not function since it needs to 'run' at compile time for initializers) for going from PCB_VISIBLE to GAL_LAYER_NUM. Simply added a PCB_GAL_LAYER to do the LAYER_NUM to GAL_LAYER_NUM domain cross (little more than a cast, actually). Luckily there is (until now) need to do the reverse (which is impossible in the general case...). Aside note: GAL_LAYER_NUM could be a base class and PCB_VISIBLE and LAYER_NUM could be subclasses. It seems to me that the IS-A relationship holds. However in C++ that would be actually very inconvenient since you can't have literal instances... except maybe in C++x1; so I'm keeping the enum representation which works and (un)fortunately has an implicit conversion to int. The idea is that all the 'view' stuff shouldn't be contaminated by LAYER_NUM to ensure future reuse. Seems quite interesting. As far I understand - you have already introduced the changes? If yes - may I have a look at them? I was also considering using classes for storing layers information (name, visiblity, rendering order, always-on-top, etc), but for the time being I would rather not introduce too many changes to the used model. First strange thing I found: the ViewGetLayers seems to be a callback (added in EDA_ITEM, probably) to interrogate an object and schedule it's drawing (or something like that, didn't study the whole trip). The returned array seems to be of GAL_LAYER_NUM values (it make sense). The fact that LAYER_NUM values are valid and correct GAL_LAYER_NUM values is an (handy!) coincidence. Generally, it was done on purpose. As you already know - some of items had to be drawn on a few separate layers (eg. THT pad is drawn on THT pad layer, hole is on a different layer and its label is another one). We did not want to prepare a totally different set of layers, parallel to the one that is already used (as copper layers are perfectly fine for drawing items that belong to those), so only a few necessary layers were introduced. As far as I rememember, one of the reasons was the Cairo backend, which does not allow (or at least I could not find a sensible way) to move freely between layers. The only way to draw is layer by layer, in contrary to OpenGL when you can specify Z coordinate. Besides that, it was necessary for determining which layers have to be updated when an item is modified. However in ROUTER_PREVIEW_ITEM::ViewGetLayers, the GP_OVERLAY value is stored back (the type is PCB_DISPLAY) which interpreted as a GAL_LAYER_NUM would go more or less in the via display layers... should it be instead ITEM_GAL_LAYER(GP_OVERLAY) or did I miss some trick along the way? Nope, there is no trick - thanks for spotting this, you are quite watchful. Good that it works, but it should be ITEM_GAL_LAYER(GP_OVERLAY), soon to be changed. By the way I find the view machinery most interesting, good work with that! ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Drawing loop in VIEW::draw
To make it easier to follow the drawing routines, it is good to go in that order: common/drawpanel_gal.cpp:119 (onPaint()) - OnPaint event handler common/view/view.cpp:766 (Redraw()) - Chooses the area that has to be redrawn common/view/view.cpp:591 (redrawRect()) - Iterates through layers sorted by their renderingOrder and checks if a layer should be redrawn. If it is the case, then there is a visitor (drawItem) that collects VIEW_ITEMs from R-Tree associated with the given layer and then performs actual drawing. If a VIEW_ITEM was cached - then it simply redraws a group, otherwise it creates a group and caches it. Groups are handled by rendering backends and are identified only by their number (think of it as a handle) and there is a 1-to-1 relation between group id and VIEW_ITEM/layer combination. On 11/01/2013 05:06 PM, Lorenzo Marcantonio wrote: Another thing that's not clear to me in the GAL mechanism. VIEW::draw, if I got correctly the algorithm should go like this: - Ask the view for the needed GAL_LAYER_NUMs - Depth sort them for cairo (and probably for correct GL blending) - For each layer in sorted order - Set the Z depth - Draw the object in question My question is this: the m_layers member is a set which is most probably accessed by GAL_LAYER_NUM (example: VIEW::SetLayerVisible); the members of the set are of the internal VIEW::VIEW_LAYER struct type (which contains obviously useful stuff). However, the call m_gal-SetLayerDepth( m_layers.at( i ).renderingOrder ); uses as index (i.e. as a GAL_LAYER_NUM, if I got it right) the i index, which is simply the progressive index in the sorted array of GAL_LAYER_NUM to be drawn. Wouldn't that be: m_gal-SetLayerDepth( m_layers.at( layers[i] ).renderingOrder ); (layers is the sorted draw order) ? Otherwise I can't guess how should it work (especially the type of m_layers...) The draw() routine you are asking about is only used when drawing a VIEW_GROUP object. Its purpose is to hold a bunch of VIEW_ITEMs together (do not mix it with group identifiers used by rendering backends). Probably I should find another name for that to avoid confusion. VIEW_GROUPs are particularly useful when drawing on the overlay layer (destined for drawing temporary objects) and in that case you may need to draw a single item layer by layer rather than drawing layer by layer, but using all items. For usual drawing of items, you should have a look at draw():607 - this is where caching VIEW_ITEMs/redrawing groups happen. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] bitset:set( -1 )
Hi Dick, Sorry for all the troubles associated with the GAL, but surely soon it will get stable. The reason is, as you suspected - an unexpected layer in the file. I propose the patch from the attachment, I think it is better to treat unknown layers as COMMENTS. Still I am wondering - how does KiCad handle items with negative layer numbers by default? Unfortunately, there is one more bug that offsets module drawings (it is visible with the board you had sent), I will take care of that tommorrow. Regards, Orson On 11/02/2013 01:48 AM, Dick Hollenbeck wrote: Orson, I found a bug which fires the new assert I added in line 372 of include/view/view_item.h The aLayer element at index zero is -1, and fires a bitset:set() std:exception. I also added a catch somewhere to keep the program from crashing on other similar issues. The bug is fired by loading an eagle board from EAGLE_PLUGIN::Load(). Load() succeeds. But in SetBoard() we go into the VIEW setup stuff and get into trouble. Maybe there is a layer in this eagle board you are not expecting? Once I ignored the exception the board displays OK in wxDC mode. Previous to that it was a bear to find, since nobody was in position to catch a std::exception. Attached is the eagle board. Any help is appreciated. I don't think you need eagle binaries to do the load, just select pcbnew's EAGLE_PLUGIN as you load a new board into KiCad. Dick ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp === modified file 'pcbnew/eagle_plugin.cpp' --- pcbnew/eagle_plugin.cpp 2013-11-02 00:24:38 + +++ pcbnew/eagle_plugin.cpp 2013-11-03 20:01:55 + @@ -2681,8 +2681,8 @@ case 95:kiLayer = ECO1_N; break; case 96:kiLayer = ECO2_N; break; default: -//D( printf( unsupported eagle layer: %d\n, aEagleLayer );) -kiLayer = -1; break; // some layers do not map to KiCad +// DBG( printf( unsupported eagle layer: %d\n, aEagleLayer );) +kiLayer = COMMENT_N; break; // some layers do not map to KiCad } } ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Drawing loop in VIEW::draw
On 11/01/2013 09:24 PM, Lorenzo Marcantonio wrote:
On Fri, Nov 01, 2013 at 05:35:10PM +0100, Maciej Sumiński wrote:
Groups are handled by rendering backends and are identified only by their
number (think of it as a handle) and there is a 1-to-1 relation between
group id and VIEW_ITEM/layer combination.
That makes suspiciously easy to use display lists or VBOs:P
Indeed, that was the reason to use the above solutions. Cairo uses
something similar to display lists (they call it groups too).
Another thing I've seen mentioned around: targets?
Targets are used for compositing. Right now, there are 3 targets available:
- CACHED - For items that are expected not to change for at least a few
frames (eg. pads, tracks, and so on). These are kept in GPU memory and
are the fastest to be rendered.
- NONCACHED - It is for items that are likely to disappear/appear every
now and then. An example of that are pad tracks labels - they appear
at a certain zoom. They are gathered in a single batch and sent to GPU
for rendering.
- OVERLAY - This is for additional items, that may change even if the
viewport stays the same. Here goes for example selection area box or
changes introduced by push shove router.
Also I can't see a thing when I switch to cairo (my fault probably).
Maybe, but I have just discovered another bug - you will not see
anything until you load a board. Check if it is your case.
VIEW_GROUPs are particularly useful when drawing on the overlay layer
(destined for drawing temporary objects) and in that case you may need to
draw a single item layer by layer rather than drawing layer by layer, but
using all items.
For usual drawing of items, you should have a look at draw():607 - this is
where caching VIEW_ITEMs/redrawing groups happen.
MMmmm more or less is clear. Could you check that loop anyway? otherwise
I can't find a way to match types.
In the loop (view.cpp:646-650):
for( int i = 0; i layers_count; ++i )
{
m_gal-SetLayerDepth( m_layers.at( i ).renderingOrder );
draw( aItem, layers[i], aImmediate );
}
'i' is the index to the LAYER_MAP. You can safely use LAYER_NUM here (or
rather GAL_LAYER_NUM). I finally got what you have meant - yes, there
should be:
m_gal-SetLayerDepth( m_layers.at( layers[i] ).renderingOrder );
as you suggested. It is fixed in the attached patch.
Now at least it compiles and links, and that's a major step...
however it... well... doesn't work exactly fine:D it seems that somehow
the layer mapping got messed up so I can always see pads, for example,
but never traces. Other things are correctly shown hidden... Some
tracing required
And now, for something completely different: there is a 'should not
occur' condition which actually happens. In D_PAD::ViewGetLayers only
the copper side of the pad is considered, and I'm not sure it's entirely
correct: for example the first case considers pads on both front and
back pushing in the requested layers both mask and paste (but I suppose
that's only a slight inefficiency). Often however dummy pads are used
for paste reduction or mask controlled openings. These are pads which
resides in no copper layer. I think the best way to handle this function
would be to loop over the pad layer mask and simply add the flagged
layers. Of course the ITEM_GAL_LAYER entities would still need special
treatment.
I have never seen such case before in the boards that I have for
testing. But if you say so, I think it could be changed. I just hope it
will not drop performance significantly. Maybe the solution you have
mentioned should be applied as a last resort?
Regards,
Orson
=== modified file 'common/view/view.cpp'
--- common/view/view.cpp 2013-10-14 18:40:36 +
+++ common/view/view.cpp 2013-11-03 21:44:43 +
@@ -645,7 +645,7 @@
for( int i = 0; i layers_count; ++i )
{
-m_gal-SetLayerDepth( m_layers.at( i ).renderingOrder );
+m_gal-SetLayerDepth( m_layers.at( layers[i] ).renderingOrder );
draw( aItem, layers[i], aImmediate );
}
}
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Misc findings during GAL_LAYER_NUM work
On 11/02/2013 05:38 PM, Lorenzo Marcantonio wrote: OK, I think I've got bug-for-bug compatibility with trunk in my branch, the split of the GAL layer number seems to work fine now. I know that it's all in early phase and work in progress, so I feel 'normal' that many things are not working (like color changing, the zoom function - and why meta-F1/F2 and not F1/F2 like before, can't hide some things and show on). It would be great to put such stuff on a list, so it will not be forgotten and I can handle it when I am done with more important bugs. However since nobody ever mentioned yet there seems to be an off-by-one error or a polygon misclosing in the zone edge drawing: when there is an 'hole' in a zone instead of closing it and lifting the pen, jumps drawing to another area (with the pen down:P). Then how do you recognize holes while drawing? I thought that only 'end_contour' needs checking. I am not very fond of the approach of the PCB_PAINTER, which contains and switch-dispatch drawing of entities... why not delegate as usual to the single BOARD_ITEMs? (or maybe define a PCB_PAINTABLE interface, or something) It is a matter of approach, I prefer to split model and view to different classes. Although - it is possible for drawable items to include routines for drawing. An example is selection box, it is drawn by ViewDraw(). The role of the PCB_PAINTER is to draw those items that may occur on a PCB. Also, more like of a curiosity, why use deques in the stroke font code? I'm a little rusty with STL but vectors seems a more likely fit... given the usage pattern I feel there's something with the performance of vector::push_back (IIRC deques allocate in blocks, I don't remember the details). Also for some reason text drawn with opengl is less 'crisp'... maybe it's the coordinate rounding, I don't know. Correct me if I am wrong, but using vectors may lead to many reallocations if you resize it (as you have to assure continuous data space) and deques are cheaper for dynamic resizing. Although I see a few spots, where it could be optimized - vectors are good when you know the size apriori. What do you mean by 'crisp' text? In comparison to the default renderer or Cairo? At last, the details on the type split: it works exactly at expected. The 'trick' is as before in layers_id_colors_and_visibility.h, attached as a preview for the curious ones, full code in my branch. It still uses the enum implementation so people which didn't like it a couple years ago still will not like this one :D GAL_LAYER_NUM has in fact the same numeric values of the int previously in use, however is better protected since it's not an int and it's type checked. Macros ITEM_GAL_LAYER and PCB_GAL_LAYER are used for moving from the PCB_VISIBLE/LAYER_NUM domain to GAL_LAYER_NUM. Sadly these are macros (and ugly ones) because these need to be used in const exprs, so overloaded operators or functions can't be employed... *maybe* the new constexpr keyword could help, I don't know exactly how it works. I'm pretty sure there is no performance penalty since all of these conversion can be actually compiler folded. For experience I know g++ is sufficiently smart. For the reverse thing: at the moment getting back the LAYER_NUM from a GAL_LAYER_NUM is in ROUTER_TOOL, members pickSingleItem and updateStartItem. I hand coded a substitution inline, probably the best way to handle it is to use a conversion function with a behaviour like dynamic_cast, returning UNDEFINED_LAYER if the conversion can't be done (or maybe trigger an exception/assert?). I am not very familiar with push shove code, but I guess it should be enough. Probably those functions work with copper layers (for which LAYER_NUM and GAL_LAYER_NUM should be equal). Another nuisance: even if LAYER_NUM IS-A GAL_LAYER_NUM (in the Liskov sense, too), enum are deemed distinct and can't inherit, so there is a need for overload utility functions (look for IsCopperLayer); as usual a class and the new class literals would help, but I don't know how much they are stable/implemented (look here http://www.preney.ca/paul/archives/636). Also they are only in gcc 4.7, I think, so it's not a lightweight decision to take. Of course this is only if you like the type safe approach; if you want it I can backpatch to trunk; if you just want the type tag as a typedef for better code documentation only (like it was done for LAYER_NUM/LAYER_MSK) I can prepare a patch for this too. Otherwise just don't care about it:P:P I like the idea, but I am not the one to decide whether it should be commited or not. As I would like our changes to be merged, I ought to stick to the master repository and its rules. Anyway, I am really thankful for such a careful code review. Some of bugs may become fixed before discovered by users and other remarks gave me a few thoughts about the code. Regards, Orson ___ Mailing list:
Re: [Kicad-developers] GLEW not found by cmake + fix
Hi Edwin, Thank you for the patch, hopefully it will get commited soon. I did not even expect /usr/lib has to be added explicitly, but if it solves the issue - why not? Regards, Orson On 11/02/2013 12:35 PM, Edwin van den Oetelaar wrote: Running a very common Ubuntu 12.4.3 building from repo did not work. Could not find the GLEW library. Adding this patch fixed it. Greetings, Edwin van den Oetelaar bzr diff === modified file 'CMakeModules/FindGLEW.cmake' --- CMakeModules/FindGLEW.cmake2013-08-27 08:32:39 + +++ CMakeModules/FindGLEW.cmake2013-11-02 11:13:42 + @@ -67,6 +67,8 @@ FIND_LIBRARY( GLEW_GLEW_LIBRARY GLEW /usr/openwin/lib /usr/X11R6/lib + /usr/lib + /usr/lib/x86_64-linux-gnu ) ENDIF (APPLE) ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Cairo rendering backend
Does anyone have anything against disabling switching (remove its hotkey and menu entry) to Cairo backend? I think it may only give a bad impression to users, as it is too slow for comfortable work. I am going to maintain it in case that there are changes in the GAL, but as it was said in the beginning - its main purpose is for PDF generation or printing. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Cairo rendering backend
On 11/05/2013 07:40 PM, Wayne Stambaugh wrote: On 11/5/2013 4:33 AM, Maciej Sumiński wrote: Does anyone have anything against disabling switching (remove its hotkey and menu entry) to Cairo backend? I think it may only give a bad impression to users, as it is too slow for comfortable work. I am going to maintain it in case that there are changes in the GAL, but as it was said in the beginning - its main purpose is for PDF generation or printing. Regards, Orson I'm fine with disabling it. It's not useful for display rendering even on my home computer which is very fast. I can't image how slow it must be on an older system or laptop. Is there any other reason to Cairo rendering around? It could be used as a fallback renderer, but right now it is too slow for that, so - in fact, there is no sensible reason. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Cairo rendering backend
On 11/07/2013 07:12 PM, Torsten Hüter wrote: Hi Orson, thanks for the great work! When I've developed the Cairo backend, my idea was not only to use Cairo for printing but also as rendering engine for eeschema. For example compare GEDA gschem, they use there Cairo as well and the screen output looks in my opinion much better than eeschema (antialiasing / freetype fonts). On my machine I've found Cairo not that slow for smaller boards - but I have an Intel Core I7. Perhaps it makes sense to hide the Cairo switch in another menu entry? There is also a third backend that I've written last year, Orson has not included it - it uses wxDC. But wxDC has some drawbacks, it does not support transparency. Perhaps still useful as fallback solution .. Bye, Torsten Hi Torsten, To tell the truth, I must have missed the source code for wxDC backend. Maybe it is worth a try, but probably now it would have to be adapted to the changes introduced to GAL. If you have a more or less working version, maybe you can compare performance of both backends? The performance drop in Cairo case is caused by cairo_push_group()/cairo_pop_group() - it was the only way for me to make the output consistent with OpenGL. I bet it could go faster for the price of looking a bit strange in areas where items (eg. tracks) overlap. If anyone is more curious about that - I can do some tests and show examples. Regards, Orson *Gesendet:* Donnerstag, 07. November 2013 um 18:59 Uhr *Von:* Wayne Stambaugh stambau...@verizon.net *An:* Kein Empfänger *Cc:* kicad-developers@lists.launchpad.net *Betreff:* Re: [Kicad-developers] Cairo rendering backend On 11/7/2013 12:36 PM, Maciej Sumiński wrote: On 11/05/2013 07:40 PM, Wayne Stambaugh wrote: On 11/5/2013 4:33 AM, Maciej Sumiński wrote: Does anyone have anything against disabling switching (remove its hotkey and menu entry) to Cairo backend? I think it may only give a bad impression to users, as it is too slow for comfortable work. I am going to maintain it in case that there are changes in the GAL, but as it was said in the beginning - its main purpose is for PDF generation or printing. Regards, Orson I'm fine with disabling it. It's not useful for display rendering even on my home computer which is very fast. I can't image how slow it must be on an older system or laptop. Is there any other reason to Cairo rendering around? It could be used as a fallback renderer, but right now it is too slow for that, so - in fact, there is no sensible reason. Regards, Orson Doesn't it make more sense to fallback to the wxDC rendering? It's known to work well except under certain conditions on OSX. You cannot perform any editing other than using the PS router so I'm not sure that it's very useful as a fallback. Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Cairo rendering backend
On 11/07/2013 08:30 PM, Dick Hollenbeck wrote: On 11/07/2013 01:03 PM, Maciej Sumiński wrote: On 11/07/2013 07:11 PM, Dick Hollenbeck wrote: On 11/07/2013 11:59 AM, Wayne Stambaugh wrote: On 11/7/2013 12:36 PM, Maciej Sumiński wrote: On 11/05/2013 07:40 PM, Wayne Stambaugh wrote: On 11/5/2013 4:33 AM, Maciej Sumiński wrote: Does anyone have anything against disabling switching (remove its hotkey and menu entry) to Cairo backend? I think it may only give a bad impression to users, as it is too slow for comfortable work. I am going to maintain it in case that there are changes in the GAL, but as it was said in the beginning - its main purpose is for PDF generation or printing. Regards, Orson I'm fine with disabling it. It's not useful for display rendering even on my home computer which is very fast. I can't image how slow it must be on an older system or laptop. Is there any other reason to Cairo rendering around? It could be used as a fallback renderer, but right now it is too slow for that, so - in fact, there is no sensible reason. Regards, Orson Doesn't it make more sense to fallback to the wxDC rendering? It's known to work well except under certain conditions on OSX. You cannot perform any editing other than using the PS router so I'm not sure that it's very useful as a fallback. Wayne What is a fallback renderer? i.e. when would it be used? It could be used when OpenGL renderer does not work. I am not really sure if eg. Intel Atom integrated graphics is able to use it. I have seen a glewinfo report that states the GPU is compatible only up to OpenGL 1.4, which is 11 years old. I hope it was only an issue of having not appropriate drivers. Regards, Orson Please think about this: At what point is is cheaper to buy the KiCad user a new computer, than it is to write software for his incompatible computer? cost of development is = man-hours x cost of a man-hour The question needs to be asked. Likewise, it needs to be asked, can the project blacklist computers and CPUs which are known to not work? Where does the commitment to support inadequate hardware/software end? Of course, the answer depends on each developer. But with the current cost of computers, as low as they are, please do not expect much of little old me regarding support of inadequate computers. Dick In fact, I am quite glad that you think so. It is sensible for me too, when I want to play the newest games, I have to buy a computer that is strong enough to handle them instead of asking for lower hardware requirements. In this case - the only question I have is: should we drop Cairo support completely or disable it, but still leave it for eg. printing? I have heard that wxWidgets 3.0 does a good job with that, but I have not tried myself yet. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Cairo rendering backend
On 11/07/2013 10:10 PM, Lorenzo Marcantonio wrote: On Thu, Nov 07, 2013 at 01:30:44PM -0600, Dick Hollenbeck wrote: At what point is is cheaper to buy the KiCad user a new computer, than it is to write software for his incompatible computer? Well, toughbooks are not exactly cheap even on the used market :D I don't know where you live but here machines about 5-10 years old are pretty normal; at least try to support the 5 year old ones:D (beside: incompatibility of new PCs with win3.1 software IS an issue... we have a lot of virtualboxes running for this) Even these days Intel/Tungsten GPUs are everywhere on the middle/low end laptop segment, so I think it's not a good idea to say 'will only works on ATI or NVIDIA'. Also many open drivers are not exactly up to speed with the latest hardware. I have never said that it only works with nVidia or ATI (I would rather suspect that ATI could make issues) - I have an integrated Intel GPU in my notebook and it works fine. So if it is not really unconvenient to develop for, I'd stick with the low-end of the graphics API. As for Intel GPUs wikipedia confirms that opengl 2 is only from the 960/965 on. Previous GPU seems to do only pixel shading (and only with 1.4 extensions). Question: do we really need gl2 for kicad? I can't think of something useful which couldn't be done with the usual fixed function pipeline. Probably you could do that with the fixed pipeline, but shaders are used to speed up things. For example - to draw a circle you may use one triangle and shade it, so it appears as a very smooth circle. With fixed pipeline you have to draw a triangle fan, consisting of as many triangles as you wish to make the circle look like a circle (as far as I remember at first it was 64 triangles, before introducing shaders). Another case are lines, you either have to draw them with a certain width. If you zoom out too far, they should still be drawn, at least 1 pixel wide. It gives you choice - resend lines in a batch every time one zoom in/out or keep them in GPU memory (VBO) and shade them to the right width. To use vertex buffer objects, that drastically increase the performance, you need to support at least OpenGL 1.5. The other extension that is used are framebuffer objects. In the specification it says that it requires OpenGL, but somehow Intel Atom GPUs that are said to support OpenGL up to version 1.4 lack that feature.. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Ratsnest for the GAL
On 11/08/2013 03:24 PM, Dick Hollenbeck wrote: On 10/16/2013 03:19 PM, Dick Hollenbeck wrote: On 10/16/2013 09:32 AM, Maciej Sumiński wrote: On 10/16/2013 02:59 PM, Dick Hollenbeck wrote: On Oct 16, 2013 7:53 AM, Dick Hollenbeck d...@softplc.com mailto:d...@softplc.com wrote: Looks promising, and super job on the presentation. Once you have it working, give some thought to using a special purpose allocator for the elements of your container. A memory pool scheme, anchored on the container, might pay dividends if it removes the size test for element allocations. If you want the pool anchored on the container, then overloading operator new is not best, but rather have a container function do the allocations of its elements (from a pool it owns.) Invariably this means having an in place new operator for the element, not a normal new operator overload. Such anchoring of pool in container is a separate decision from deciding to use a fixed block allocator at all. The fixed block allocator will be worth it regardless of where the pool lives. If you have to move elements from one container to another, then anchoring the pool on the container is not appropriate. But you could then have a class that held all your containers and a pool common to those containers. I bring this up because when instantiating hundreds of thousands of elements, memory heap calls can be the bottleneck. Thanks for the suggestion - I like the idea. I have briefly read the boost::pool project page and initially it seems to be an easy solution to the problem. That is likely to be a *very* fast solution. But keep in mind that if you are going to delete the pool, since it is anchored in your ratsnest class, then you really don't need element deletion, i.e. operator delete () on the container element. This let's you trancend into *very very* fast, if you use it to your advantage. The problem with supporting pool::free( node ) is that it often requires that a pointer to the big block from which the smaller fixed size block came be saved in the smaller block. There may be other ways, look into this. This additional pointer, if present, is unnecessary if you don't worry about delete node, since the pool is going to be deleted anyways. The pointer is a way to figure out which big block to add the small fixed block back into upon a free. It is overhead you don't need. Just saving that one pointer can be a big deal. If the boost scheme is doing this, or if its allocation function uses more than about 3 lines of code, then it may not be optimal. Also, if your algorithm can work with pointers to the node, where moving nodes from one container to another is really a matter of moving pointers, you will also pick up some speed. What I envision is that when the pool would be inclined to return NULL, meaning the current big block is exhausted, that it allocate another big block and then put that big block onto a linked list of big blocks, singly linked is good enough. After that, it puts each small block within the big block onto another singly linked list, called a freelist. Each of the lists are held in the pool anchor. The anchor destructor frees all the big blocks. operator delete () can be a dummy for the node element, I assume you will need one since the container destructor may be calling it, and this happens before the pool destructor hopefully. Especially that nodes are very likely going to be POD structures with fixed size. I guess it is already included in C++11 as the emplace() function that is available for many std containers. Orson, You reminded me of a couple of things: a) regardless of whether in place new() is used or not, if the objects have std::string or wxString, the objects will need destruction to free up their string internals. The objects very well may need a ~destructor(). I am almost sure that structures that describe nodes and connections are not going to contain strings. It will be rather a small simple POD, so it should perfectly fit memory pool scheme. b) emplace() is a modern way of doing old school memory block management with in place new(). Real time C++ programmers have been using in place new for awhile. emplace() is an opportunity to use a stock container, but has been limited to C++11. But boost, in it effort to bring early functionality even to *C++03*, has emplace() support on boost::container::vector *and* boost::container::deque So for a minimal lines of code implementation of what I was talking about above, a person could simply put a boost::container::deque into your ratsnest class and allocate objects quickly from there, simply by adding them to the deque with emplace(), and returning a pointer to the back(). This is minimal lines of code and I doubt there's a faster way, especically with so few lines of code. http://www.boost.org/doc/libs/1_48_0/doc/html/container/move_emplace.html
Re: [Kicad-developers] Cairo rendering backend
On 11/08/2013 11:48 PM, Torsten Hüter wrote: Hi Orson, have a look here: http://bazaar.launchpad.net/~kicad-testing-committers/kicad/kicad-gal/view/head:/gal/wxdc/wxdc_gal.cpp With my test examples it was faster than Cairo. I guess it should be possible to reach the same performance like the old drawing routines. Downside is the missing transparency and that wxDC drawing is deprecated. Bye, Torsten I would rather stick to Cairo in such case, as disabling transparency probably would give a huge speed up and adapting the wxDC backend to the current GAL interface could take some time. Regards, Orson Hi Torsten, To tell the truth, I must have missed the source code for wxDC backend. Maybe it is worth a try, but probably now it would have to be adapted to the changes introduced to GAL. If you have a more or less working version, maybe you can compare performance of both backends? ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] boost gcc 4.8.1
Boost downloaded by KiCad does not build with gcc 4.8.1 - it is already resolved in boost-trunk. I do not know what is the policy for applying patches that are going to be included in the mainstream, but just in case - the attached patched removes the problem. Regards, Orson === modified file 'patches/boost.patch' --- patches/boost.patch 2013-05-31 04:46:02 + +++ patches/boost.patch 2013-11-11 10:27:18 + @@ -18,3 +18,16 @@ itrT2 tmpb = bb; ++tmpb; +=== modified file 'boost/cstdint.hpp' +--- boost/cstdint.hpp boost/cstdint.hpp +@@ -42,5 +42,8 @@ + // See https://svn.boost.org/trac/boost/ticket/3548 and http://sources.redhat.com/bugzilla/show_bug.cgi?id=10990 + // +-#if defined(BOOST_HAS_STDINT_H) (!defined(__GLIBC__) || defined(__GLIBC_HAVE_LONG_LONG)) ++#if defined(BOOST_HAS_STDINT_H) \ ++ (!defined(__GLIBC__) \ ++ || defined(__GLIBC_HAVE_LONG_LONG)\ ++ || (defined(__GLIBC__) ((__GLIBC__ 2) || ((__GLIBC__ == 2) (__GLIBC_MINOR__ = 17) + + // The following #include is an implementation artifact; not part of interface. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] boost gcc 4.8.1
On 11/11/2013 11:47 AM, Brian Sidebotham wrote: On 11 November 2013 10:32, Maciej Sumiński maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch wrote: Boost downloaded by KiCad does not build with gcc 4.8.1 - it is already resolved in boost-trunk. I do not know what is the policy for applying patches that are going to be included in the mainstream, but just in case - the attached patched removes the problem. Regards, Orson By the looks of it this is a 32-bit OS problem only? I certainly don't have a problem with Boost compiling on Windows 7 x64 and KiCad-Winbuilder is also using mingw32-w64 4.8.1 and compiles okay. I don't have a 32-bit system to test on. It's certainly not *just* gcc 4.8.1 and Boost anyway. Best Regards, Brian. Then it may be related to Linux exclusively, as I use 64 bit too and the error occurs. More details can be found at: https://svn.boost.org/trac/boost/ticket/8973 Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] boost gcc 4.8.1
On 11/11/2013 04:00 PM, Dick Hollenbeck wrote: Hi Orson, On 11/11/2013 11:47 AM, Brian Sidebotham wrote: On 11 November 2013 10:32, Maciej Sumiński maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch wrote: Boost downloaded by KiCad does not build with gcc 4.8.1 - it is already resolved in boost-trunk. I do not know what is the policy for applying patches that are going to be included in the mainstream, but just in case - the attached patched removes the problem. CMake's ExternalProject_Add() can apply multiple patches, using the COMMAND continuation. (BTW all *_COMMANDs can be continued with COMMAND. I used to use for command continuation, but this requires a shell, not there on Windows.) Since each patch applied via CMake's ExternalProject_Add() is a separate wish for upstream, and some of those battles will be won and some lost, we are probably best served by keeping our patches separate rather than combining them. This way on the next release of say, boost, the patches they did not take can easily persist if need be on our end, rather than us having to doctor our combined patch file. This is what I committed. Hopefully it will work for you on linux gcc 4.8.1. It works, the problem is gone now. Thank you. Regards, Orson Thanks for digging this out. Dick Regards, Orson By the looks of it this is a 32-bit OS problem only? I certainly don't have a problem with Boost compiling on Windows 7 x64 and KiCad-Winbuilder is also using mingw32-w64 4.8.1 and compiles okay. I don't have a 32-bit system to test on. It's certainly not *just* gcc 4.8.1 and Boost anyway. Best Regards, Brian. Then it may be related to Linux exclusively, as I use 64 bit too and the error occurs. More details can be found at: https://svn.boost.org/trac/boost/ticket/8973 Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [Bug 1250876] Re: DisplayError / tool_manager.cpp compile failure
On 11/13/2013 05:46 PM, Dick Hollenbeck wrote: On 11/13/2013 09:28 AM, Wayne Stambaugh wrote: Fix committed in r4463. ** Changed in: kicad Status: New = Fix Committed tool_manager.cpp: line 142 is using concatonation against a format string, this is a bug. If you want formatting, we need wxString::Format() or the new std::string StrPrintf() or similar. If the format string is not going to be translated, then there are savings by going down to an 8 bit string. On linux, wxT() creates a 32 bit string, which takes up 4 times the memory of an 8 bit string. Further consideration has us anticipating a transition to wx 3.x on all platforms, at which point we can remove all wxT() instances, supposedly. That also will be a transition to 8 bit constant strings, one we have to wait for. So there are two paths forward, both sensible, one you have to wait for. The deciding factor for me is that aTool-GetName() returns const std::string so we start with an 8 bit string. So I offer the attached patch. Thank you for the correction, I really need to be more careful. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Boost dependencies
Today I saw an error during the boost build:
fatal error: bzlib.h: No such file or directory
Would not it be good to add bzip2 dependency to download_boost.cmake
script, so users will get a clear message before an attempt to build the
library?
Regards,
Orson
=== modified file 'CMakeModules/download_boost.cmake'
--- CMakeModules/download_boost.cmake 2013-11-12 12:44:30 +
+++ CMakeModules/download_boost.cmake 2013-11-14 16:22:33 +
@@ -58,7 +58,7 @@
#-/configure---
-
+find_package( BZip2 REQUIRED )
string( REGEX REPLACE \\. _ BOOST_VERS ${BOOST_RELEASE} )
set( PREFIX ${DOWNLOAD_DIR}/boost_${BOOST_VERS} )
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boost dependencies
Thank you Brian, sorry for the problem - I hope not many people were affected by the dependency. Regards, Orson On 11/17/2013 12:34 AM, Brian Sidebotham wrote: This did break KiCad-Winbuilder, but I released an update with libbz2 building enabled. So it's all good. From the Boost Documentation: On Windows, the zlib and bzip2 filters are disabled by default; to enable support for these filters, you will need to set variables indicating the location of the source files, if building from the source, or the location of the headers and binaries, if using pre-built binaries. http://www.boost.org/doc/libs/1_54_0/libs/iostreams/doc/installation.html So it seemed reasonable to include it now in case we need it in the future for some reason. Best Regards, Brian. On 16 November 2013 13:43, jp charras jp.char...@wanadoo.fr mailto:jp.char...@wanadoo.fr wrote: Le 16/11/2013 12:27, Maciej Suminski a écrit : I cannot explain why, it was just an observation - I attach the log that made me think so. Does it break builds on Windows? Regards, Orson On 11/15/2013 10:01 PM, Brian Sidebotham wrote: This dependency is not required on Windows? How come the Linux build needs it and the Windows build doesn't? What boot library was throwing the error? Best Regards, Brian. Does it break builds on Windows? Currently, yes, because under Windows it is not needed, and if this dependency is added, one should build and add this lib to mingw. Under Windows, I removed this dependency. In fact, when you build boost libs, the files used to build them are not exactly the same between Linux and Windows. So the fact bzip2 is needed on Linux and not on Windows is curious, but no fully surprising. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] A tribute to KiCad quality
I like this one even more: http://www.kickstarter.com/projects/mossmann/hackrf-an-open-source-sdr-platform And I bet that people contributing to KiCad have some more good examples. Regards, Orson On 11/18/2013 10:48 AM, Martijn Kuipers wrote: Dear devs, I am in no way affiliated to this site, but it shows that KiCad is used to change the way things work. This site is an excellent example of the quality of KiCad and I sincerely hope they reach the funding to build their system: http://mobilecg.hu/ Keep up the great work (both the KiCad team as well as the Mobile ECG team), Martijn ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Ratsnest release note
Ladies and Gentlemen, Finally, there is the ratsnest compatible with the GAL available for testing in our branch [1]. Hopefully after some testing time and main developers approval, it will get merged to the testing branch. The main difference introduced is that the ratsnest now takes into account tracks and vias too. It came at some performance cost, but it should not be a very big price for the functionality. For those that are slightly more interested in implementation details: - The board is processed, ie. all items are split to nodes (connection points such as pads, vias, track endings) and connections (tracks). - Basic grid of connections if computed by Delaunay triangulation (ignores the fact if connections exist or not, just prepares the grid). It is done using the TTL[2] library, tailored to the needs of the algorithm. - Minimum spanning tree is computed, taking into account if connections exist or not. For the items that are modified by the tools, it takes too much time to recompute the whole ratsnest, so there is only one line drawn for each node. After modifications are finished, all nets that were influenced are refreshed. Things that I would like to add in the nearest future: - pool allocators - I believe this should significantly increase the speed, but I was not able at the time being to use it properly to gain some boost. I just need some experiments to combine those with shared_ptrs. - toggling ratsnest per net - There could be a menu for hiding specific nets. I used to hide power nets in my designs, as they were introducing lots of missing connections that were littering my screen. As usual, both tests and opinions are more than welcome. Myself, I am going to further develop the selection tool. Kind regards, Orson [1] lp:~cern-kicad/kicad/ratsnest [2] http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/ ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] - Fix for compiling on ARM CPUs
Thank you for sharing the solution. I have to admit that the ARM build happened faster than I thought it will. Regarding rdtsc() - in fact, you may return 42, but the proper function would be great. As the header name says - it is only for execution time measurements and it is not critical for the application operation. By the way - did not you have any problems with OpenGL? Kind regards, Orson On 11/25/2013 05:21 PM, Robert Yates wrote: Two problems to fix in order to allow compiling for ARM. The first was to add the proper Boost::Context assembly wrapper files for ARM, and modify common/system/fcontext.s to include them. The files 'jump_arm_aapcs_elf_gas.S' and 'make_arm_aapcs_elf_gas.S' I acquired from the boost_1_55_0.tar.bz2 download from http://www.boost.org/ The second parch is for a fake rdtsc() function in include/profile.h to make the compiler happy. I'm not a c++ programmer so I don't actually know what the right thing to do is, but I'm sure returning the number '42' isn't it. ;-) There seems to be a cycle counter register built into ARM CPUs similar to the TSC register in x86 CPUs, but reading it is not trivial just google 'arm cycle counter' to see what I mean. But with these two patches I'm able to compile under Arch linux ARM on my Chromebook (http://archlinuxarm.org/platforms/armv7/samsung/samsung-chromebook) and it seems to be running well. Both patches are against revision 4499 of the lp:kicad branch. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Next steps
As I have recently mentioned, the new ratsnet (available for testing in lp:~cern-kicad/kicad/ratsnest) could be improved in a few ways. This is an opportunity to use your skills in a very advantageous way. If you feel like helping the project, then have a look at: http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades I would be also very thankful for reviewing the proposal for extension of the Selection tool: http://www.ohwr.org/projects/cern-kicad/wiki/Selection-tool I am particularly interested in the main developers' view about points: - Cut/copy/paste - Undo/redo If there are no objections from the main developers, then we invite other programmers to join - you could do a great contribution. Do not hesitate to ask questions or express opinions, your input is very important. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Next steps
On 11/28/2013 01:10 PM, Martijn Kuipers wrote: On Nov 28, 2013, at 12:07 PM, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Thu, Nov 28, 2013 at 10:56:42AM +0100, Maciej Sumiński wrote: I am particularly interested in the main developers' view about points: - Cut/copy/paste Never felt a need for copy/paste on a board... YMMV of course (perhaps for modular I/O stages or such?) I can see it be fun to be able to Cut Paste from one board to another. For instance, copy the switching power supply part as a whole. Just my 2 cents. /Martijn Both could be good use cases, but now when I think about it, this is not as easy as it seemed to be in the beginning. As far as I know currently there is no back annotation (you cannot update schematics basing on a PCB file), so modules that were copied may introduce some disorder. They need nets to be connected to (this could be cloned, but I am not sure if that is the right way, especially in case of pasting parts from another board), value and reference (value could be copied too and reference could be just the next free number). The things may get more complicated when you reload .net/.cmp file - I think those parts can just disappear, as they are not in the list. I need to reconsider the feature again, maybe there are some good solutions to that. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Next steps
On 11/28/2013 09:58 PM, mj wrote: On 11/28/13 13:10, Martijn Kuipers wrote: On Nov 28, 2013, at 12:07 PM, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Thu, Nov 28, 2013 at 10:56:42AM +0100, Maciej Sumiński wrote: I am particularly interested in the main developers' view about points: - Cut/copy/paste Never felt a need for copy/paste on a board... YMMV of course (perhaps for modular I/O stages or such?) I can see it be fun to be able to Cut Paste from one board to another. For instance, copy the switching power supply part as a whole. CutPaste would be nice :). But I guess it'll be used to repeat parts of an schematic which should be solved in an more elegant way - treat board layouts as parts. Sure, you'll need some special part in eeschema to denote a track as connection to the other board. I am not sure if I got it right - are you talking about subschematics or schematics blocks (have a look at demos/complex_hierarchy.sch that is delivered with KiCad source code)? And then, in case you have multiple blocks using the same pattern in schematics (e.g. a few ADCs with filters) to duplicate parts layout on the board? Sounds confusing to make no difference between parts and layouts? Parts and boards only differ in in the fact that an board can may have more layers compared to a part (and no tracks in parts - why?). Layers are all the same - besides we can only use the outer copper layers... If we go a bit deeper, the microwave tool (create line of specific length) already puts an module into the boards layout - but it'll discard all information about the length of the track - which was the curial part about the created segment... Besides this, the statements inside the module it created, are quite close to the information about tracks, only missing the net and timestamp. Imho we've got some redundant elements here (fp_line vs. segment). But if we use normal tracks to make such modules, how do we keep the user from deforming those tracks? Add some special joints to mark some super-segment, between those joints, it should be impossible to edit the single segments, only move them as whole (like the microwave part before). Is it called 'rooms' in the Altium's nomenclature? (For non-Altium people: http://www.youtube.com/watch?v=dYgvRCrVeOI / http://wiki.altium.com/pages/viewpage.action?pageId=22872356). Like said above, the difference between the parts and boards is not that big. If we would place the add pad button in pcbnew (and an field for partname), we could ditch the complete module editor (which you can only reach by starting pcbnew). Ditching the module editor may be not such a good idea, you still need an editor for preparing footprints. And still it does not solve the problem of backannotation. Stuff like Zones for multichannel layouts (terms from Altium) would be nearly implemented that way, you would only need the option to select a complete board as footprint for an entire subsheet (or create a symbol for the board and don't use the whole schematic as subsheet). Goind this way, one would not end with, say 16 times, the same layout which he has to edit if something was wrong - just re-import the footprint (aka layout) and you are done. Maybe I'm wrong with my view about the current situation in kicad, in this case I would like to know why :). Cya, imp The idea itself is great, but needs some more consideration regarding the implementation. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Next steps
On 11/29/2013 11:29 AM, mj wrote: (...) What do you call the one in demos/complex_hierarchy? It's reusing the same schematic twice with differnent annotations (done this before, saves quite some time doing a switch matrix - but with hierarchy labels). Guess if it's using hierarchy labels, it's a subschematic in your terminology? I am talking about those files: http://bazaar.launchpad.net/~kicad-testing-committers/kicad/testing/files/head:/demos/complex_hierarchy/ If you open the schematics, you will find two embedded blocks referencing to other schematic files that I call subschematics (I do not know the proper name in the KiCad world). But it seems that we agree about the subject, it is just the naming that may differ. (...) Ditching the module editor may be not such a good idea, you still need an editor for preparing footprints. And still it does not solve the problem of backannotation. Given it's possible to use boards as parts and add pads pcbnew, it should replace the module editor - or am I still missing some important parts? But would not it mean that after dropping the module editor you are limited only to the footprint libraries that were created before? (Or create new footprints using vim/emacs?). Or rather do you mean to compose boards from other board files containing footprints? I think the latter could work, but probably there reasons to keep them separate. Probably the main developers could shed some light on the topic. How about preparing a blueprint, so we could collaborate on that further, have some comments from others? (And do not let it become forgotten). Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Character codes clamping
I was looking through the text drawing routines and I am wondering if font code clamping works as expected. It seems that for characters with codes higher than the font description table size it should draw '?' instead of characters. But in the function common/drawtxt.cpp:GetHersheyShapeDescription() it first assigns '?' character and then subtracts 32 resulting in a different character than the question mark. Please have a look at the attached patch and check if I got it right. Maybe it is not a big deal and it will not crash pcbnew, but still it is better when things work as expected. Regards, Orson === modified file 'common/drawtxt.cpp' --- common/drawtxt.cpp 2013-06-29 09:52:22 + +++ common/drawtxt.cpp 2013-12-03 09:35:42 + @@ -150,7 +150,7 @@ int font_length_max = newstroke_font_bufsize; if( AsciiCode = (32 + font_length_max) ) -AsciiCode = '?'; +AsciiCode = 32 + '?'; if( AsciiCode 32 ) AsciiCode = 32; // Clamp control chars ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Character codes clamping
Nevermind, it was just a short circuit in my head, I did not get it right. Regards, Orson On 12/03/2013 10:46 AM, Maciej Sumiński wrote: I was looking through the text drawing routines and I am wondering if font code clamping works as expected. It seems that for characters with codes higher than the font description table size it should draw '?' instead of characters. But in the function common/drawtxt.cpp:GetHersheyShapeDescription() it first assigns '?' character and then subtracts 32 resulting in a different character than the question mark. Please have a look at the attached patch and check if I got it right. Maybe it is not a big deal and it will not crash pcbnew, but still it is better when things work as expected. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] BOARD_ITEMs removal
I am digging through the code responsible for BOARD_ITEMs removal and I have a few questions that are probably easy to answer for people, who know the source code better than I do. I have found two places where removal happens: - void PCB_EDIT_FRAME::RemoveStruct( BOARD_ITEM* Item, wxDC* DC ) called when there is only one item to remove (user pressed the Delete key when an item was under the cursor) - void PCB_EDIT_FRAME::Block_Delete() used for removal of block of items (user selected a block of items, right-clicked and chose Delete block) Why are they handled in a different way? Is it only to avoid multiple ratsnest compilations or refreshing the whole canvas vs xoring single items to erase? There are also various way to remove items: - void BOARD_ITEM::UnLink() void BOARD_ITEM::DeleteStructure() - BOARD_ITEM* BOARD::Remove( BOARD_ITEM* aBoardItem ) void BOARD::Delete( BOARD_ITEM* aBoardItem ) I can easily say the difference between BOARD_ITEM::Unlink DeleteStructure or BOARD::Remove BOARD::Delete, but I am not able to say why BOARD_ITEM::Unlink() and BOARD::Remove() coexist. Do not they simply remove items from DLISTs stored in the BOARD class? Thanks in advance, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Blueprint for layouts as parts
It seems that users are looking forward to the feature: http://groups.yahoo.com/neo/groups/kicad-users/conversations/messages/16647 Regards, Orson On 12/01/2013 06:59 PM, Martin Janitschke wrote: Heyho, I've created the blueprint [0] we've started to discuss in the Next Steps thread. Comments are welcome :). The blueprint partially supersedes [1] [2] due to the fact that Pcbnew will make it way easier to create panelized boards by hand and the overhead to create the schematics for the whole board is now minimal. (1. Add sub-sheets, assign the correct schematics, 2. select the correct boards in CvPcb, 3. move the boards next to each other (without the old hassle to select the whole board, move the already panelized boards out of the way before appending the next one...)). Bye, imp [0]: https://blueprints.launchpad.net/kicad/+spec/layouts-as-footprint [1]: https://blueprints.launchpad.net/kicad/+spec/add-panelize-to-pcbnew [2]: https://blueprints.launchpad.net/kicad/+spec/append-board ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxAui improvements.
On 12/09/2013 04:25 PM, Wayne Stambaugh wrote: On 12/9/2013 10:14 AM, Maciej Sumiński wrote: On 12/09/2013 03:06 PM, Wayne Stambaugh wrote: On 12/9/2013 3:49 AM, Maciej Sumiński wrote: On 12/07/2013 01:42 AM, Wayne Stambaugh wrote: I have just committed a small change to the testing branch (r4529) to the Pcbnew footprint viewer that will allow the main toolbar to be dockable. I would like some feedback about how well saving and loading the window state between session works on various platforms before I start to do this to all of the KiCad application main frame windows. The wxAui stuff was put in place a few years ago with the intent that all of the fancy layout features would be enabled. Since that hasn't happened I thought I would start working on it incrementally rather than get carried away an create a lot of problems. When you have some spare time, please test it and let me know if there are any major issues. I don't have wxWidgets 3 on my Linux partition and no access to OSX so feedback from those users is very important since I cannot test those platforms. Thanks, Wayne Hi Wayne, It is a great idea to have dockable toolbars. I tested it with wxWidgets 2.8/Linux and the freshest wxWidgets 3.0 and in general it works fine and the position of toolbar is saved. One major problem I stumbled upon is that while using wx3.0, I somehow lost the toolbar and now I cannot recover it. It could be an issue of my window manager, but anyway - it could be good to have a menu where one can toggle toolbars visibility. Regards, Orson Hey Orson, You should not be able to close the footprint viewer tool bar. I intentionally have the close button disabled. If you managed to close it, then there is a bug in wxWidgets. What platform and wxWidgets version where you using when this occurred? If I can duplicate it, I might be able to fix it. As I apply this to the other KiCad apps, I will add menu entries to show tool bars that have been closed. Unfortunately the footprint viewer does not have a menu so I may have to do something about that in the future if we want to be able to hide the tool bars. Thanks for the help with testing. Cheers, Wayne I am not really sure, but it was rather wx3.0/Linux. As I said - I cannot recover the toolbar now, so I am not able to reproduce the issue at the moment, but I am going to try again on a different machine. My window manager does not display titlebars, neither close/minimize/maximize buttons, so I just close windows by using a hotkey and it could be the case. I will confirm it later. Cheers, Orson That's strange. I'll see if I can duplicate it. You can get the footprint viewer toolbar back by deleting the ModViewFramePerpective entry from the .pcbnew configuration file in you home folder. This will return the footprint viewer back to it's default position and size the next time you open it. Thank you for the hint. Now I am sure that I closed it using a hotkey, as in every other case (both wx2.8 3.0/Linux x64) it is saved restored correctly. Also, I am not sure if it is possible with regular window managers, but if I close the pcbnew window before the footprint viewer, the position is not saved, but the previous one is used. Cheers, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Footprints licence
There was an interesting question asked on the #kicad irc channel: as there is the GPL licence note (COPYRIGHT.txt) included in the library repository, how does it affect PCBs created with the libraries? Are the boards created using the library repository also licenced under the GPL? As footprints are stored in .kicad_pcb files, it could be compared to static linking of GPL software libraries, so the whole design should be licenced under the GPL. Am I right or different rules apply? Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] BOARD_ITEMs removal
On 12/18/2013 09:00 PM, Wayne Stambaugh wrote: On 12/4/2013 2:06 PM, Maciej Sumiński wrote: I am digging through the code responsible for BOARD_ITEMs removal and I have a few questions that are probably easy to answer for people, who know the source code better than I do. I have found two places where removal happens: - void PCB_EDIT_FRAME::RemoveStruct( BOARD_ITEM* Item, wxDC* DC ) called when there is only one item to remove (user pressed the Delete key when an item was under the cursor) - void PCB_EDIT_FRAME::Block_Delete() used for removal of block of items (user selected a block of items, right-clicked and chose Delete block) Why are they handled in a different way? Is it only to avoid multiple ratsnest compilations or refreshing the whole canvas vs xoring single items to erase? There are also various way to remove items: - void BOARD_ITEM::UnLink() void BOARD_ITEM::DeleteStructure() - BOARD_ITEM* BOARD::Remove( BOARD_ITEM* aBoardItem ) void BOARD::Delete( BOARD_ITEM* aBoardItem ) I can easily say the difference between BOARD_ITEM::Unlink DeleteStructure or BOARD::Remove BOARD::Delete, but I am not able to say why BOARD_ITEM::Unlink() and BOARD::Remove() coexist. Do not they simply remove items from DLISTs stored in the BOARD class? Thanks in advance, Orson Orson, The only reason I see that BOARD::Remove() has to stay is that MARKER_PCB and ZONE_CONTAINER objects are not stored DLISTs. They are std::vectors so BOARD_ITEM::Unlink() would not remove them from a vector. I'm not sure why this was done this way. If they were changed to DLISTs, BOARD::Remove() could be eliminated. Wayne Thank you for the explanation, it is quite clear now. I am going to investigate if it can be changed without creating new problems, in order to unify this and avoid confusion. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] The Selection Tool improvements
Ladies and gentlemen, Here comes another portion of goodies for the selection tool. I would be very grateful for some testing/opinions/suggestions, before I propose them for merging. The newest changes are available in the branch lp:~cern-kicad/kicad/selection_tool. From now on, you can: - edit properties of items using the default KiCad dialogs (double click on an item or select an item and then choose properties from the context menu/press 'E') - remove items - changes are stored in the default KiCad undo buffer, so they are consistent between renderers (you may do some changes using the default tools and revert them while using GAL or the other way round) - you do not need to explicitly turn on the selection tool, it is enabled by default and it stays active forever - the bottom status bar is updated, showing informations about the selected item - file modification flag is updated after a change is done - pads are not changeable anymore, as it does not work well with the KiCad's way of handling footprints (they should be rather modified using the footprint editor) Although the plan [1] is still not fully realized, the update should allow to design a PCB using mostly the GAL renderer. It may seem that there is a bug regarding bounding box of selected texts, but it is resolved in another branch that I am going to propose for merging soon. Using the opportunity, I would like to, on behalf of our small CERN KiCad group, wish peaceful and joyful Christmas to the whole KiCad community. Regards, Orson [1] http://www.ohwr.org/projects/cern-kicad/wiki/selection-tool ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The problems with wxString
On 01/01/2014 07:58 AM, Dick Hollenbeck wrote: On 11/21/2013 02:16 PM, Dick Hollenbeck wrote: 1) wx = 2.9 has these constructors wxString( const char* ) wxString( std::string ) whereas wx 2.8 does not. Both offer: wxString( const char*, wxConvUTF8 ); but this cannot be used in a default type promotion situation, this constructor must be invoked explicitly. 2) The above type promotion constructors treat the input encoding as that of the current locale, rather than UTF8 assuredly. The type promotion constructors are important if you want to allow the compiler to promote an 8 bit string to a wxString for you without special syntax. 3) If you decide to keep 8 bit strings in memory, encoded in the current locale, then someday when you load a chinese board file, you will not be able to hold those strings in a deficient 8 bit encoding. (UTF8 is not a deficient 8 bit encoding, some others are.) The software breaks at that point. This argues for using UTF8 always as the internal 8 bit encoding. But now the above two constructors are broken, since the current locale's encoding cannot be assumed to be UTF8, even though it often is on linux. You just cannot assume it. In summary, I don't see any easy immediate relief from the boat anchor we know as wxString, even with wx 3.0. But I will continue to think about it. Dick Attached is a patch needing a good look, that shows off a new class UTF8 that I wrote that solves the problems addressed above by providing conversion operators to and from wxString, yet holding UTF8 data in what is basically a std::string. Please say how it impacts you, realizing its usage scope can be trimmed or expanded from this sampling. I am especially interested in: a) how it compiles on gcc = 4.8 b) how it compiles using clang. c) what it does to any benchmarks of sane-ness and speed for stroke_font.h Lorenzo, Marco, Orson, your feedback in particular is wanted. class UTF8 will likely allow the removal of many many more calls to TO_UTF8() and FROM_UTF8(), not in this patch. Plus code size will likely be reduced because I put the size expensive stuff out of line in a lean call interface. Dick Everything compiles works fine with gcc 4.8.1 and wx 3.0. As there is not much code contributed by us that works with strings - I do not see anything that I could be missing. After some simple performance tests, I confirmed my expectations (and Lorenzo's as well) that it does not affect rendering speed noticeably. I was wondering about some modifications of the uni_iter class to make it usable with functions available in algorithms in the standard library (e.g. https://gist.github.com/jeetsukumaran/307264/). It should not require a lot of changes, if you want - I can try it out. One trap that I can see is having both iterator (from std::string) and uni_iter. It may lead to situations when one uses std::string::iterator (just by habit or was not aware how does it work) and what really meant is uni_iter. In my opinion if the class is specifically designed for UTF8, we could drop the std::string iterator. Besides that - everything is fine with me. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] The problems with wxString
On 01/02/2014 07:04 PM, Dick Hollenbeck wrote: In my opinion if the class is specifically designed for UTF8, we could drop the std::string iterator. It is, but it is for strings, not UTF8 character manipulation. Its best use is at the edge of the system in helping with serialization and de-serialization to disk, clipboard, other byte oriented peripherals TBD. Futurer brain interfaces, etc. whatever needs 8 bit data. As I said before, if I wanted to rewrite wxString, I would have done it in one line of code via: typedef std::basic_stringuint32_t MYSTRING; One might even call it wxUString: http://docs.wxwidgets.org/trunk/classwx_u_string.html But my intent with class UTF8 was not to *replace* wxString. It was to overcome the 3 stated deficiencies, and only those, such that serialization to 8 bit strings was easier to look at. Definitely not. There are few expected side effects to treating it like a std::string. If you find one, I'd rather you work in wxStrings. Now that the 3 stated deficiencies of using wxString are gone, that makes my objections to using wxString also gone. This was achieved by augmentation from the outside. Dick It was just my opinion, but given the arguments and some more thoughts, now it seems more and more sensible. As my concerns were related only to naming, not the implementation - it would be good to apply the patch and see the new class in action. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boost building as an option
On 01/06/2014 06:34 PM, R P Herrold wrote: On Mon, 6 Jan 2014, Maciej Sumiński wrote: I can fully understand that it is much easier for many users not to deal with building boost library, but on the other hand - there are many others who do not need a separate copy of boost just for KiCad. ... I look forward to your opinions. I tested it with boost 1.54.0-3 (that is the reason why I put such version as required in CMakeLists.txt) and gcc 4.8.2. Adding the new option to omit the local boost re-build makes sense in all cases, as it can be defaulted to retain the present behaviour during testing. I have a build cycle of 75 minutes because of the Boost build, after a 'make clean', rather than the ten or so for kicad otehrwise. It is another good reason for giving user a choice. An alternative approach would be do add a make target between 'make clean' and nothing, which only 'cleans' out the non-Boost parts I suppose That could help, but only for 'make clean' part. Myself I rarely do it, rather I create new branches or modify CMakeLists.txt that forces KiCad to rebuild boost. Is this patch as to omiting the local kicad build of boost, available via a 'git' branch, that I might test it? I am not sure if it will that way, but you may try to trim the beginning and the end of the patch. If it does not work, the crucial part is: === modified file 'CMakeLists.txt' --- CMakeLists.txt 2013-12-31 10:42:25 + +++ CMakeLists.txt 2014-01-06 16:25:26 + @@ -44,6 +44,11 @@ Builds Kicad and all libraries static (except wx-widgets) ) +option( KICAD_BUILD_BOOST +Downloads and builds necessary boost components (you should enable the switch if your system +does not contain boost libraries) +) + # when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled: # PYTHON_EXECUTABLE can be defined when invoking cmake # ( use -DPYTHON_EXECUTABLE=python path/python.exe or python2 ) @@ -317,7 +322,17 @@ # Download boost and possibly build parts of it # -include( download_boost ) +if( KICAD_BUILD_BOOST ) +include( download_boost ) +else() +find_package( Boost 1.54.0 REQUIRED COMPONENTS context date_time filesystem iostreams locale + program_options regex system thread ) + +if( NOT Boost_FOUND ) +message( FATAL_ERROR Boost 1.54+ libraries are required. You have either to install + appropriate packages or build KiCad with KICAD_BUILD_BOOST switch enabled. ) +endif() +endif() ## # Find wxWidgets library # The rest is merely cleaning stuff, it does not influence build time. Thank you You are welcome, Orson -- Russ herrold ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boost building as an option
On 01/06/2014 07:58 PM, Wayne Stambaugh wrote: On 1/6/2014 12:00 PM, Maciej Sumiński wrote: I can fully understand that it is much easier for many users not to deal with building boost library, but on the other hand - there are many others who do not need a separate copy of boost just for KiCad. As far as I know, there are 3 main reasons to keep boost in KiCad (https://lists.launchpad.net/kicad-developers/msg11692.html): Ad 1) I guess the patch that fixes the geometry problem is patches/boost_minkowski.patch. But inside there are only two lines commented out and in fact they seem to be variables that are not even used anywhere. How does that influence the function output? Or is not it already solved by switching optimization options (already done in the main CMake script)? Ad 23) For those people included boost can make life simpler. So why not give a choice to build another copy or use the library available in system? I came to the conclusion after having 8 different branches, every of them containing compiled boost library. And it seems that KiCad builds and works just as well using the boost library included in my system. The attached patch: - Adds a CMake option KICAD_BUILD_BOOST that enables building boost. If you think that boost should be downloaded and built by default (I guess that eg. KiCad-WinBuilder could be influenced by that), I can change it to KICAD_SKIP_BOOST and satisfies me as well. Besides that, boost can downloaded and built when an appropriate version is not available in system. - Removes all context related files (common/system/*), as they are anyway contained in boost and no longer necessary. - Removes the last traces of KICAD_STABLE_VERSION and KICAD_TESTING_VERSION from bundled documentation. I look forward to your opinions. I tested it with boost 1.54.0-3 (that is the reason why I put such version as required in CMakeLists.txt) and gcc 4.8.2. Regards, Orson Orson, I prefer building Boost myself but a little historical perspective is needed to understand why we opted to download and build Boost. Long before the geometry library issues were the Windows build issues. We (Dick, JP, and myself) spent a considerable amount of time helping Windows developers with Boost build issues. There were also a lot of KiCad build bugs related to which version of Boost was installed on on Linux as well. Thank you for the explanations. I expected that boost comes with KiCad to make building easier for some users, but I did not even think of bugs related to version of the library. Newer versions of Boost would break builds and the CMake FindBoost() macro only tests for a minimum version not a specific version. It can be forced to check for specific version of the library using EXACT keyword. But I can imagine it helps only a little, as usually Linux distributions / Mac OS ports do not offer you a variety of versions, but the most recent one that was prepared by package maintainers. Finally the decision was made to use CMake to download and build a specific version of Boost for the sanity of the lead developers. This way we had absolute control over the Boost version and then later the patches to fix the geometry library bug. If memory serves, the GCC optimization fix was for a different bug than the geometry patch. It finally became a choice of the lesser of two evils. I'm not opposed to this change but it should come the a stern warning that if you choose build KiCad using the installed version of Boost on your system and it breaks *you* get to keep both pieces and not to expect a lot of help from the lead developers. Sounds reasonable to me. In this case I will prepare a patch, that leaves building boost as the default option and displays a message if user decides to keep his version. After that, it will not break any of current build systems, but still allows to reduce build time/occupied disk space for every branch. Regards, Orson Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Boost building as an option
On 01/06/2014 10:46 PM, Marco Serantoni wrote: On 06/gen/2014, at 21:27, Maciej Sumiński maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch wrote Thank you for the explanations. I expected that boost comes with KiCad to make building easier for some users, but I did not even think of bugs related to version of the library. Many of the issues I had on OSX are related to to wrong compilation or choices, restrict and be sure about which is the library used is a nice first step to be able to support users. Newer versions of Boost would break builds and the CMake FindBoost() macro only tests for a minimum version not a specific version. It can be forced to check for specific version of the library using EXACT keyword. But I can imagine it helps only a little, as usually Linux distributions / Mac OS ports do not offer you a variety of versions, but the most recent one that was prepared by package maintainers. Maciej, package maintainers doesn’t do a good work as we have done I and Dick lately on boost, just take a look to the patches applied and the related tickets. Our current boost patched release doesn’t exists already neither in the Development branch of boost. The support in boost::context for OSX was almost NONE, there was a ticket laying there for 10 months, no option for building (i386/x86_64) no option at all for building PPC32/PPC64, options that now is in our repository and building. The same is the support for GNU AS/MINGW on Windows. Take a look to tickets url near the patches in the CMakeModules/download_boost.cmake file I’ll expect to see if boost 1.56 will contain those feature before moving on “normal distribution” channels. Moreover i’m asking myself which is the best final distribution of kicad, i think that normal users will use binaries not a build from scratch, and i think that request normal users on the different platforms one version of library could be practicable with difficulties, i don’t see normal users install ports on OSX, additional libraries on Windows and moreover knowing well how works linux distributions that still have seasoned libraries on stable trees (RHAS , Debian Stable) and probably advance quickier on the more fast distributions (Fedora, Debian testing/unstable) having a large plethora of different flavour of configurations and releases to obfuscate tickets diagnose. Same difficulties I will see deploying the software in an large organization and the interaction with systems for the configuration management. Is this a good choice to pick ? I build already for 2/3 platforms at once, i can understand better than all which are the problems/flags you are raising. — Marco I really understand your view and appreciate your efforts, as thanks to your work KiCad is able to reach a wider group of users. In fact, one of the patches was proposed by me, as I had problem with a specific version of gcc and I am very glad that it was accepted. I also struggled to make our contribution work on the main platforms (Linux, Windows, Mac OS). What I am trying to achieve is to reduce the time that is required to build KiCad. Maybe not everyone will appreciate that, as probably most of users builds KiCad every now and then (and CMakeLists.txt does not change so often), but I hoped it may help some developers. As I said - now I have 8 branches, but in total I went through many more. At CERN I have quite good hardware at my disposal that really speeds up development, but at home it is totally different. Even if there is no appropriate boost package available for a Linux distribution, people may have an option to build boost once (I guess it should be possible to install it somewhere as well) and then other branches may just use that version. With regard to the above, I am not voting for full removal of boost, as I still see the point of simplifying the build steps. All I ask for is one switch. As Wayne suggested - if boost building is enabled by default and there is a clear warning that disabling it is done on one's own responsibility, then it should be enough to keep the build procedure simple and discourage people who are not sure if the option should be applied or not. If everyone agrees that it is just a bad idea, then I am not going to insist any further, but I do not think it may cause any serious harm. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Net names and net codes
I am wondering if there are any special reasons to keep net names and
net codes separated. This gives programmer a chance to set a net code
that is actually not related to the appropriate net name. One is even
able to set a net name that does not exist using D_PAD::SetNetname() for
a single pad or a group of pads.
I have seen that in many places there are pairs of functions:
item-SetNet( .. );
item-SetNetname( .. );
but if I recall correctly, that is not always the case.
Also, net names are kept (and directly available) only for some specific
classes (D_PAD, ZONE_CONTAINER, they are delivered via different
functions - respectively GetNetname() and GetNetName()) but not all
BOARD_CONNECTED_ITEMs (TRACK and its derivatives does not contain this
information). For classes that miss net name, there can be used
NETINFO_ITEM, which stores both net code and net name. Again, question
arises - is it done on purpose?
Another thing that I observed is that net codes may be subject to change
during edition of a board (I guess it happens when you remove all pads
that belong to a single net). As I understand, it is to keep net codes
consecutive, but it also disallows to reliably index items using their
net codes. Is the only right way to index items by nets is to use their
net names?
As I am not as familiar with the KiCad's core as you are, then I would
like to ask what do you think of:
- removing m_Netname m_ShortNetname fields from D_PAD and m_Netname
from ZONE_CONTAINER
- use net codes to refer to a specific NETINFO_ITEMs, that actually
store useful informations for nets
- adding something similar to (it actually exists in the code as
ZONE_CONTAINER::SetNetNameFromNetCode()):
wxString BOARD_CONNECTED_ITEM::GetNetname() const
{
BOARD* board = GetBoard();
if( board == NULL )
return wxString( );
NETINFO_ITEM* netinfo = board-FindNet( m_NetCode );
if( netinfo == NULL )
return wxString( );
return netinfo-GetNetname();
}
wxString BOARD_CONNECTED_ITEM::GetShortNetname() const
{
BOARD* board = GetBoard();
if( board == NULL )
return wxString( );
NETINFO_ITEM* netinfo = board-FindNet( m_NetCode );
if( netinfo == NULL )
return wxString( );
return netinfo-GetShortNetname();
}
or improve it to make it faster, if it is necessary.
Regards,
Orson
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Net names and net codes
On 01/08/2014 04:39 PM, jp charras wrote: Le 08/01/2014 15:35, Maciej Sumiński a écrit : I am wondering if there are any special reasons to keep net names and net codes separated. This gives programmer a chance to set a net code that is actually not related to the appropriate net name. One is even able to set a net name that does not exist using D_PAD::SetNetname() for a single pad or a group of pads. I have seen that in many places there are pairs of functions: item-SetNet( .. ); item-SetNetname( .. ); but if I recall correctly, that is not always the case. Also, net names are kept (and directly available) only for some specific classes (D_PAD, ZONE_CONTAINER, they are delivered via different functions - respectively GetNetname() and GetNetName()) but not all BOARD_CONNECTED_ITEMs (TRACK and its derivatives does not contain this information). For classes that miss net name, there can be used NETINFO_ITEM, which stores both net code and net name. Again, question arises - is it done on purpose? Net names come from the netlist created by the schematic. Because a netlist knows only pads numbers, net names are stored in pads, to handle netlist info. A net code is a number only for internal use, equivalent to the net name, and used to compare, sort ... nets (just because compare 2 numbers is faster ans easier than compare 2 strings. The net code is only for internal use, and has no meaning outside pcbnew. Zones store a net name because they are connected to a net name which comes from the netlist. (An issue happen when this net name does not exist after a schematic change, and the user should edit this zone when it net name is lost. By the way, Pcbnew currently crashes in RN_LINKS::AddNode(), when reading a board which contains a zone which has a non existent net name, i.e. which has a net code = -1) Tracks do not store the net name but just the net code, because they are expected to be connected to pads which store this info. (this is the reason tracks and vias not connected to a pad lose their net after loading a board, or reading a netlist) Therefore, after loading a board, or reading a netlist, the track net code should be initialized, but you have to store this net name in pads. (Of course, one can use an other way to store net names, and an other way to calculate net codes) Therefore net names cannot be easily removed from pads, unless rewriting the way net codes are set from net names. I do not know if rewriting that is worth (nad I do not see an advantage to change this). However zones should store a net name anyway, because the user set a zone net name, not a zone net code (which is not equivalent, after schematic changes, because netlists do not store info for zones). Having both GetNetname() and GetNetName() is certainly a bug. One is enough. The short net name is only used to display the net name. It could be computed on the fly from the full net name (which includes the sheet path). It exists only for computing time reasons, to display the net name in pads on screen. (m_ShortNetname can be removed, if the cost to calculate it is small) Thank you, now the principles are much clearer to me. But is not some kind of net code stored in .kicad_pcb files? You can find there lines where both net code and net name are stored, e.g.: (net 5 GND) (net 6 N-04) or (pad 6 thru_hole oval (at 1.27 -3.81 270) (size 1.5748 2.794) (drill 0.812799) (layers *.Cu *.Mask F.SilkS) (net 2 /pic_sockets.sch/CLOCK-RB6)) or (zone (net 5) (net_name GND) (layer Cuivre) (tstamp 48F6319A) (hatch edge 0.508) For tracks, it looks like only net code is saved: (segment (start 181.61 124.46) (end 182.88 123.19) (width 0.635) (layer Cuivre) (net 3)) Net codes change only in void NETINFO_LIST::buildListOfNets() function and only if all items from a given net were removed. I wonder if it would not be better if this kind of cleaning was done on file save. The reason why I ask about this is the ratsnest implementation for the GAL. I index items by their net codes, so ratsnests are separate for every net. In this way, I wanted to update only nets that were changed, instead of recreating the whole ratsnest. Besides that, storing net names only in one place (e.g. NETINFO_ITEM) makes code less prone to errors, as then there is no possibility to have a pad with a net name that does not exist or have net code and net name that do not match each other. Regarding the RN_LINKS::AddNode() bug - right now I am coupling the ratsnest algorithm with improved tools, so I will fix it soon. Regards, Orson Another thing that I observed is that net codes may be subject to change during edition of a board (I guess it happens when you remove all pads that belong to a single net). As I understand, it is to keep net codes consecutive, but it also disallows to reliably index items using their net codes. Is the only right way to index items by nets is to use their net names? As I am
Re: [Kicad-developers] Net names and net codes
On 01/09/2014 04:51 PM, jp charras wrote: Le 09/01/2014 11:22, Tomasz Wlostowski a écrit : On 01/08/2014 04:39 PM, jp charras wrote: Tracks do not store the net name but just the net code, because they are expected to be connected to pads which store this info. (this is the reason tracks and vias not connected to a pad lose their net after loading a board, or reading a netlist) Therefore, after loading a board, or reading a netlist, the track net code should be initialized, but you have to store this net name in pads. (Of course, one can use an other way to store net names, and an other way to calculate net codes) Hi Jean-Pierre, I see another point in modifying the net assignment mechanism. If we allow tracks/vias to retain net names and propagate them from the pads only when the schematic netlist has changed (not every time the board is loaded), it would also fix the infamous zone stitching issue... Regards, Tom Stitching vias and generally speaking not connected (to a pad) items (stitching vias, usual vias and tracks) create an other problem than retaining the net name. Retaining the net name of items not connected to a pad (or a zone) items is easy to fix (I already received a patch to do that). But the major issue is: if the net names are retained in not connected (to a pad) items, all track ends and vias should be included in the ratsnest generation. Otherwise, we will have not connected vias and/or not connected copper zone areas (floating copper islands). This is the only one reason stitching vias do not exist in Pcbnew. Therefore fixing stitching vias issue is: 1 - finish and validate (this is the more important step toward stitching vias) the new ratsnest algorithm which takes in account pad+vias+track ends: mainly for very complex boards, see if it is fast enough. This is done by the ratsnest algorithm we added for the GAL (it is currently available in the testing branch). I have to admit that it probably is slower, but it is hard to keep the performance when amount of data for computation increases. The toughest test case I have by hand is the board that I recommended for testing the GAL (http://www.ohwr.org/attachments/download/2187/wrs.kicad_pcb), when you drag the biggest IC in the middle, as it contains the greatest number of nets connected. After being dropped you may observe a freeze for a short time, it is the ratsnest algorithm going - we have to decide if it is acceptable. The current ratsnest algorithm is very fast for 6000 pads (50 ms on my computer). What happen for 10x to 20x more (roughly 6000 pads + 3 tracks (2 point) and 3000 vias for instance) 2 - after this, Retaining the net name of items not connected. And be sure the calculation time to know if 2 items are connected by a zone area is fast. Currently, this is 90% of calculation time. Because stitching vias will create a *lot* of items connected by zones, the calculation time in a very important criteria. We take it into account during the ratsnest calculation. I agree, it takes the biggest amount of time, but still on a decent hardware is acceptable (at least in my opinion, I would like to know other views). 3 - add tools to change items net names, when a net name has changed in schematic (for instance AGND changed to GND) (easy, obviously, but needed) I think this could be handled easily if net names were kept in NETINFO_ITEM and D_PAD stored only net code or a pointer to the appropriate data. I know the ratsnest need to be rebuild only for the modified net (this is also currently the case). But the full ratsnet need to be fully rebuild, for instance when existing copper zones are modified (when creating/moving a via, for instance). This is frequently the case, for complex boards. Until now, when I was not aware of the fact that net codes are a subject to change - I indexed all items by their net codes and if anything was modified, I checked its netcode and recalculated this. This also applies to zones, vias and tracks. This is one of reasons why I wanted to keep net codes constant during a single run time. In Altium, you need to deactivate (shelve) copper polygons to be able to work on you boards when the calculation time is too long... I did not think of this, but actually it is a good hint to reduce computation time if user wants to do so. I already have the first changes proposal. As they are related to the KiCad's core, it is very important to me if you could assess if they are suitable to commit before I move on. If you have some spare time, please have a look at the lp:~cern-kicad/kicad/netnames branch. If in your opinion they do not break anything, the next step I wanted to do is to remove m_Netname/m_ShortNetname fields, move GetNetname()/GetShortNetname() to BOARD_CONNECTED_ITEM and make them use net names stored in NETINFO_ITEMs. Regards, Orson ___ Mailing
Re: [Kicad-developers] Net names and net codes
On 01/10/2014 08:45 PM, Vesa Solonen wrote: 10/01/14 19:35, Maciej Sumiński kirjoitti: the board that I recommended for testing the GAL (http://www.ohwr.org/attachments/download/2187/wrs.kicad_pcb), when you drag the biggest IC in the middle, as it contains the greatest number of nets connected. After being dropped you may observe a freeze for a short time, it is the ratsnest algorithm going - we have to decide if it is acceptable. While the big redesign/rewrite of Kicad core is going on, it might be a good moment to think some radical moves. Designing all computationally intensive parts with multi core processors, de facto available SIMD/Vector instructions and OpenCL in mind. As an example instruct the compiler to autovectorize just that ratsnest calculation. Or the previous plus function written to support multiple threads. Running the UI thread and processing threads separate, say the ratsnest being constantly iterated in the background when it changes. Just by GCC autovectorization its easy to get ten times more comparing or multiplying performane. -Vesa I fully support the idea, in fact I have dreamed about this too (http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades). I had a short try with OpenMP, but I did not get any better results, so it seems that I could have done it wrong. If there are volunteers who have some experience with parallelization I am very eager to cooperate to speed up some of computations. The ratsnest algorithm is a perfect place to start with. It is performed on per net basis, so they are all independent to each other. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Net names and net codes
Great, now it seems that we have a group of people who are experienced with the subject. I believe this has to end up with some speed up in KiCad. Regards, Orson On 01/14/2014 10:59 AM, Marco Serantoni wrote: Only the warning: keep attention that boost::context doesn't support the context switch for the vector registers (mmx*/v*). If needed i can help you to implement. -- Marco On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen vesa.solo...@aalto.fi mailto:vesa.solo...@aalto.fi wrote: 13/01/14 10:04, Maciej Sumiński kirjoitti: I fully support the idea, in fact I have dreamed about this too (http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades). I had a short try with OpenMP, but I did not get any better results, so it seems that I could have done it wrong. Some articles: http://locklessinc.com/articles/vectorize/ http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookWritingAutovectorizableCode Some tools: http://code.entropywave.com/blog/ http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk ORC may be the best tool to go with. GNU Radio's DSP stack and GStreamer depends on it. If there are volunteers who have some experience with parallelization I am very eager to cooperate to speed up some of computations. The ratsnest algorithm is a perfect place to start with. It is performed on per net basis, so they are all independent to each other. I could possibly do something, but I'm not familiar with much of the Kicad code. Single function optimise this - might work, but delivery times can't be guaranteed... -Vesa ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Net names and net codes
Hi Carl,
Thank you for putting efforts to boost the performance of the ratsnest.
The function is brought by an external library
(http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/), I am not sure
what is exactly inside. The expected output should be a Delaunay
triangulation of all nodes that are taken into account while computing
ratsnest.
The only issue I am aware of, is the function does not handle well empty
containers, but it should not be the case right now.
Now, when I looked again to the source code, RN_DATA is derived after
hed::Node class (include/ttl/halfedge/hetriang.h), which contains a
static field. Another thing is (I believe this is the main source of
troubles) static hed::Triangulation (include/ttl/halfedge/hetraits.h:73).
Sorry that I did not say about that before, but I have just discovered
that it is done that way. I will try to change it, but unfortunately
there are little chances that I manage to do that before Sunday.
Regards,
Orson
On 01/22/2014 06:08 PM, Carl Poirier wrote:
Maciej,
Can you summarize to me how the function Triangulation::createDelaunay(
nodes.begin(), nodes.end() ) works, and what are the data structures
involved?
I believe there are some dependencies in there.
On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
cirilo_berna...@yahoo.com mailto:cirilo_berna...@yahoo.com wrote:
From: Carl Poirier carl.poirie...@gmail.com
mailto:carl.poirie...@gmail.com
To: Marco Serantoni marco.serant...@gmail.com
mailto:marco.serant...@gmail.com
Cc: Kicad Developers kicad-developers@lists.launchpad.net
mailto:kicad-developers@lists.launchpad.net
Sent: Wednesday, January 22, 2014 3:51 AM
Subject: Re: [Kicad-developers] Net names and net codes
There are some things in the code that don't like being
multithreaded. If I parallelize the for loop in
RN_DATA::Recalculate( int aNet ), I get a segfault. It does not
happen if I put a lock to the call updateNet( i ), but obviously
there is no increase in performance. I'm trying to find out what's
the problem now.
This sounds to me like data is being altered by different threads
and possibly there is some memory reallocation happening (growing
arrays, etc). Locks are only needed when there is contention
somewhere and of course locks should only be held for as short as
needed. Another pitfall with threading is that some variables may
need to be declared 'volatile' if they can be altered in another
thread while one function is executing. For example, let's say the
variable 'bool someX' can be altered in 2 threads; something like
this can happen:
1. FunctionA starts, and runs a loop while(!someX) { ... }
2. FunctionB sets 'someX' to 'true'
3. FunctionA continues to run the loop, which is not the intended
behavior
Of course similar things can happen when using shared memory and
forked processes.
Threading has other problems to watch out for - for example, are
there any static variables in functions? If so then you simply
cannot thread those functions without locks.
- Cirilo
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Net names and net codes
That is a good start, I hope we can get even more performance boost now.
Could you please try the lp:~cern-kicad/kicad/ratsnest_threadsafe branch
to check if it solves the problem with createDelaunay() function?
It would be great if you shared your changes (especially if they crash
the application), so I could test them as well and look for fixes.
Regards,
Orson
On 01/24/2014 04:35 PM, Carl Poirier wrote:
I think that we will have a very great speedup if each thread can have
its own Triangulation. Just by parallelizing the loop in
RN_DATA::recalculate() but going sequentially with one Triangulation, I
still have ~25% gain in calculation time.
On Wed, Jan 22, 2014 at 2:59 PM, Maciej Sumiński
maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch wrote:
Hi Carl,
Thank you for putting efforts to boost the performance of the ratsnest.
The function is brought by an external library
(http://www.sintef.no/__Projectweb/Geometry-Toolkits/__TTL/
http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/), I am not
sure what is exactly inside. The expected output should be a
Delaunay triangulation of all nodes that are taken into account
while computing ratsnest.
The only issue I am aware of, is the function does not handle well
empty containers, but it should not be the case right now.
Now, when I looked again to the source code, RN_DATA is derived
after hed::Node class (include/ttl/halfedge/__hetriang.h), which
contains a static field. Another thing is (I believe this is the
main source of troubles) static hed::Triangulation
(include/ttl/halfedge/__hetraits.h:73).
Sorry that I did not say about that before, but I have just
discovered that it is done that way. I will try to change it, but
unfortunately there are little chances that I manage to do that
before Sunday.
Regards,
Orson
On 01/22/2014 06:08 PM, Carl Poirier wrote:
Maciej,
Can you summarize to me how the function
Triangulation::__createDelaunay(
nodes.begin(), nodes.end() ) works, and what are the data
structures
involved?
I believe there are some dependencies in there.
On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
cirilo_berna...@yahoo.com mailto:cirilo_berna...@yahoo.com
mailto:cirilo_bernardo@yahoo.__com
mailto:cirilo_berna...@yahoo.com wrote:
__
From: Carl Poirier carl.poirie...@gmail.com
mailto:carl.poirie...@gmail.com
mailto:carl.poirier.2@gmail.__com
mailto:carl.poirie...@gmail.com
To: Marco Serantoni marco.serant...@gmail.com
mailto:marco.serant...@gmail.com
mailto:marco.serantoni@gmail.__com
mailto:marco.serant...@gmail.com
Cc: Kicad Developers
kicad-developers@lists.__launchpad.net
mailto:kicad-developers@lists.launchpad.net
mailto:kicad-developers@__lists.launchpad.net
mailto:kicad-developers@lists.launchpad.net
Sent: Wednesday, January 22, 2014 3:51 AM
Subject: Re: [Kicad-developers] Net names and net codes
There are some things in the code that don't like being
multithreaded. If I parallelize the for loop in
RN_DATA::Recalculate( int aNet ), I get a segfault. It does not
happen if I put a lock to the call updateNet( i ), but
obviously
there is no increase in performance. I'm trying to find out
what's
the problem now.
This sounds to me like data is being altered by different
threads
and possibly there is some memory reallocation happening
(growing
arrays, etc). Locks are only needed when there is contention
somewhere and of course locks should only be held for as
short as
needed. Another pitfall with threading is that some
variables may
need to be declared 'volatile' if they can be altered in
another
thread while one function is executing. For example, let's
say the
variable 'bool someX' can be altered in 2 threads;
something like
this can happen:
1. FunctionA starts, and runs a loop while(!someX) { ... }
2. FunctionB sets 'someX' to 'true'
3. FunctionA continues to run the loop, which is not the
intended
behavior
Of course similar things can happen when using shared
memory and
forked processes.
Threading has other problems to watch out for - for
example, are
there any static variables in functions? If so then you simply
cannot thread those functions
Re: [Kicad-developers] KiCad-Winbuilder V3.3
Hi Adam, I am just wondering - if the KiCad-Winbuilder was run on the cluster, then what do you think about some automatized process that builds Windows binaries (for both stable product branches) and uploads them to the KiCad website (or any other place that is linked to the download page), let's say once a week or a fortnight? This way, there could be always a fresh build for Windows available for testing. I bet it could make Windows users quite pleased and also lead to more thorough testing. Even better if it was shipped with an installer, but I do not want to ask for too much. Regards, Orson On 01/30/2014 03:54 PM, Adam Wolf wrote: I would like to volunteer to help out with the Windows build and add it to the Wayne and Layne Jenkins cluster. Is there good documentation for setting it up and building it, including what sort of Windows stuff you need? I am very inexperienced with Windows. On Thu, Jan 30, 2014 at 8:18 AM, Edwin van den Oetelaar oetelaar.automatiser...@gmail.com mailto:oetelaar.automatiser...@gmail.com wrote: Congratulations to both your families. This will be the most import (and busy) part of your life. Greetings, Edwin On Thu, Jan 30, 2014 at 3:13 PM, Brian Sidebotham brian.sidebot...@gmail.com mailto:brian.sidebot...@gmail.com wrote: Thanks Miguel, it will be our first so we're very excited as well as desperately trying to at least complete the bathroom as soon as possible! We are expecting at the beginning of May. Many congratulations to you too, good luck with everything yourself! Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Net names and net codes
Hi Carl, Great job! I have just tested your patch and I confirm 2x boost on my machine as well. To tell the truth, I consider this a big speedup - particularly that you made it with just a few lines of code. RN_DATA::Recalculate() is run every time when there are changes on the board (e.g. items are moved/rotated/etc.) - it checks which nets where modified and updates the ratsnest for them. Speeding up the computation while parts are moved is obviously desired, but a bit harder to obtain, as GAL drawing functions are not thread-safe and it's not that easy to make them so. The main reason is that all items to be drawn are saved in a common buffer, so that has to be synchronized - I expect a very little boost, if any. On the other hand, this type of ratsnest is not as demanding as the one you have accelerated in terms of CPU cycles. Thank you for the efforts. I will propose your changes for merging next week, together with some new features related to the ratsnest and tools. Regards, Orson On 01/31/2014 04:17 PM, Carl Poirier wrote: Hi Maciej, Your last changes allow a complete independence of the loop iterations in RN_DATA::Recalculate( int aNet ). I have almost a 2x speedup on a Core i7-4770 with the very simple parallelization in the attached patch. I was expecting more, though. There seems to be a bottleneck somewhere. I have a question, however. Did you want to speedup the computation when you move the part? From what I see, RN_DATA::Recalculate( int aNet ) is run only when the user loads the board. Am I missing out on something? BTW, I've included in the patch some output to measure computation time, which obviously is not meant to be committed. I have also added the required build flag at the top of the CMakeLists.txt, because I don't know exactly where it should go in it. Carl On Tue, Jan 28, 2014 at 4:51 AM, Maciej Sumiński maciej.sumin...@cern.ch mailto:maciej.sumin...@cern.ch wrote: Hi Jean-Pierre, I am done with the changes that would let me rely on the net codes in other parts of code. I did my best to perform tests and put comments to each commit, so they could be easier to understand and verify. Could you please have a look at the lp:~cern-kicad/kicad/netnames branch? If you think the proposed changes do not break anything, I would be grateful for merging the branch. Thank you in advance. Regards, Orson On 01/11/2014 05:31 PM, jp charras wrote: Le 10/01/2014 18:35, Maciej Sumiński a écrit : On 01/09/2014 04:51 PM, jp charras wrote: Le 09/01/2014 11:22, Tomasz Wlostowski a écrit : On 01/08/2014 04:39 PM, jp charras wrote: Tracks do not store the net name but just the net code, because they are expected to be connected to pads which store this info. (this is the reason tracks and vias not connected to a pad lose their net after loading a board, or reading a netlist) Therefore, after loading a board, or reading a netlist, the track net code should be initialized, but you have to store this net name in pads. (Of course, one can use an other way to store net names, and an other way to calculate net codes) Hi Jean-Pierre, I see another point in modifying the net assignment mechanism. If we allow tracks/vias to retain net names and propagate them from the pads only when the schematic netlist has changed (not every time the board is loaded), it would also fix the infamous zone stitching issue... Regards, Tom Stitching vias and generally speaking not connected (to a pad) items (stitching vias, usual vias and tracks) create an other problem than retaining the net name. Retaining the net name of items not connected to a pad (or a zone) items is easy to fix (I already received a patch to do that). But the major issue is: if the net names are retained in not connected (to a pad) items, all track ends and vias should be included in the ratsnest generation. Otherwise, we will have not connected vias and/or not connected copper zone areas (floating copper islands). This is the only one reason stitching vias do not exist
Re: [Kicad-developers] [QA] Automated testing for KiCad
I guess you could run uncrustify and do a diff, but unfortunately you cannot apply uncrustify blindly - sometimes its output seems a bit odd. One possible solution is to check how many lines were corrected by uncrustify, if above a set threshold (relatively to the whole patch length) - send an e-mail to the commiter containing formatting hints. Regards, Orson On 02/04/2014 10:00 PM, Miguel Angel wrote: Hmmm, Do we have something to check coding style compliance? Not sure if uncrustify does code checking along with reformating if we had that we could automatically check submitted code for style compliance. --- irc: ajo / mangelajo Miguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2014-02-04 Miguel Angel miguelan...@ajo.es mailto:miguelan...@ajo.es: Hi!, thanks for the enthusiasm! :) 2014-02-04 Fabrizio Tappero fabrizio.tapp...@gmail.com mailto:fabrizio.tapp...@gmail.com: I completely agree. Jenkins for Kicad is going to be a blast!! I hope i could help in some how in the future. Mui bien echo macho ! Fab. On 03/02/2014 10:44 PM, inkblotter inkbot...@gmail.com mailto:inkbot...@gmail.com wrote: On 02/02/2014 04:12 PM, Miguel Angel wrote: [] Miguel, Let me applaud and encourage you in tackling this important step forward for Kicad, of automated Jenkins builds of the Kicad source and automated tests. I have worked with Jenkins doing automated builds and tests on multiple platforms in the past, albeit only with Java. I'm impressed that you are extending it to do C++ builds and tests, with the help of Python Jenkins is so modular that can be used for many automated works. I used to work with something similar (bamboo), but that's commercial software, it's good, but even if they give you a license for free, you have to keep fighting and asking for license renewals to stay updated, and ... I'm sorry, but they can't bet an rpm update, or apt-get update, etc... I do believe that any automated build and test mechanism should run on all supported platforms, both 32-bit and 64-bit. It's a good point, yes, it requires more resources, but it's probably something interesting to do. We could probably throw in a 32bit slave + win32 + win64 slaves if we have CPU, ram enough and licenses. Or we can ask for volunteers here, I know that is on Adam wolf's plans, at least for MacOSX, but I believe he was thinking of doing the same for Windows. I can't help you in the effort other than peripherally since I have other Kicad-related itches that will consume most of my available time in the next month or two. This is a huge task; you can't do automated testing all by yourself effectively. Eventually, other developers would have to contribute over time. I think this is an important step forward in any mature and stable code base. Fortunately, after the mechanism is flushed out, this can be done and enhanced incrementally over time. Yes, I'm just laying down the road, but for this to work, eventually we will need tests developed along with new code. That doesn't come for free, but it pays for itself on the longterm (for example, somebody new can come, patch something or add a feature... without the test he doesn't realize that he's breaking a few other things... but with the test he knows.. and he can do the right thing: either fix the test, or fix his new code.) Again, thanks for your efforts on behalf of Kicad. I'm happy to help. It's a project I like, and it's a project which I find very important for the future of anything related to electronics, computing, etc... without a decent free/open electronic CAD there will be no open hardware... Cheers, Miguel Ángel Ajo, ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Release note
There is a new release [lp:~cern-kicad/kicad/selection_tool] available for testing with some improvements to the tools: - undo/redo for all operations you can do in the GAL canvas - highlighted ratsnest for currently modified items (also for the PNS router) - for those who have strong habits - you can edit items in the same way as with the default canvas (hover over an item and select an operation), for people willing to try another approach - you may select items and then modify them (using hotkeys or right-click context menu) I would like to thank Carl Poirier for speeding up the ratsnest algorithm for multicore CPUs - good job! Also, for those who have not checked the selection_tool branch before, there are some other changes to experience: https://lists.launchpad.net/kicad-developers/msg11907.html As usual - I would be very grateful for some testing, before I propose the branch for merging. This time it is particularly important to me, as there are some changes to KiCad's core. This means that I really need to be sure that there is nothing broken. Now you should be able to carry out most editing steps in a more comfortable way than before. The next step is drawing tools. Please let me know what else you miss in the GAL canvas. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Release note
On 02/07/2014 01:52 PM, Wayne Stambaugh wrote: On 2/7/2014 5:29 AM, Maciej Sumiński wrote: There is a new release [lp:~cern-kicad/kicad/selection_tool] available for testing with some improvements to the tools: - undo/redo for all operations you can do in the GAL canvas - highlighted ratsnest for currently modified items (also for the PNS router) - for those who have strong habits - you can edit items in the same way as with the default canvas (hover over an item and select an operation), for people willing to try another approach - you may select items and then modify them (using hotkeys or right-click context menu) I would like to thank Carl Poirier for speeding up the ratsnest algorithm for multicore CPUs - good job! Also, for those who have not checked the selection_tool branch before, there are some other changes to experience: https://lists.launchpad.net/kicad-developers/msg11907.html As usual - I would be very grateful for some testing, before I propose the branch for merging. This time it is particularly important to me, as there are some changes to KiCad's core. This means that I really need to be sure that there is nothing broken. Now you should be able to carry out most editing steps in a more comfortable way than before. The next step is drawing tools. Please let me know what else you miss in the GAL canvas. Regards, Orson Orson, I've already tested it and I cannot find any issues with it. I do have one minor (hopefully) request. Right clicking an object does not bring up the context menu like the legacy canvas. You first have to select the object and then right click to get the context menu. Making this change should give you 100% coverage of object editing even if all of the hot keys are not yet implemented. I will also mimic the legacy canvas behavior which users are familiar with. Thanks, Wayne Hi Wayne, Thank you for testing. The idea sounds good, it is already commited in the branch - it did not require many changes. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] kicad-stable vs wxWidgets 3.x
I am wondering if the attached patch could be applied to the stable
branch. The reason is currently it does not compile with wxWidgets 3.x
at all or wxWidgets 2.x that are built without '--with-gnomeprint' or
'--with-gtkprint'. There are no wonders inside, just a few backported
changes from the product branch.
Regards,
Orson
=== modified file 'common/basicframe.cpp'
--- old/common/basicframe.cpp 2013-01-12 18:32:24.908999000 +0100
+++ new/common/basicframe.cpp 2014-02-10 08:59:50.362256003 +0100
@@ -458,8 +458,18 @@ void EDA_BASE_FRAME::AddHelpVersionInfoM
static inline const char* KICAD_BUILD_OPTIONS_SIGNATURE()
{
return
- ( __WX_BO_UNICODE __ABI_VERSION __BO_COMPILER __WX_BO_STL
-__WX_BO_WXWIN_COMPAT_2_6 __WX_BO_WXWIN_COMPAT_2_8 )
+#ifdef __WXDEBUG__
+ (debug,
+#else
+ (release,
+#endif
+__WX_BO_UNICODE __ABI_VERSION __BO_COMPILER __WX_BO_STL
+
+#if !wxCHECK_VERSION( 3, 0, 0 )
+__WX_BO_WXWIN_COMPAT_2_6
+#endif
+
+__WX_BO_WXWIN_COMPAT_2_8 )
;
}
@@ -468,7 +478,11 @@ static inline const char* KICAD_BUILD_OP
static inline const char* KICAD_BUILD_OPTIONS_SIGNATURE()
{
return
- ( __WX_BO_DEBUG ,
+#ifdef __WXDEBUG__
+ (debug,
+#else
+ (release,
+#endif
__WX_BO_UNICODE __ABI_VERSION __BO_COMPILER __WX_BO_STL
__WX_BO_WXWIN_COMPAT_2_4 __WX_BO_WXWIN_COMPAT_2_6 )
;
=== modified file 'common/common.cpp'
--- old/common/common.cpp 2013-03-30 13:54:49.36700 +0100
+++ new/common/common.cpp 2014-02-10 08:48:11.698929316 +0100
@@ -40,6 +40,16 @@
#include wx/process.h
+// Show warning if wxWidgets Gnome or GTK printing was not configured.
+// Since wxWidgets 3.0, this is no more needed (build in printing works!)
+#if defined( __WXGTK__ )
+#if !wxCHECK_VERSION( 3, 0, 0 )
+# if !wxUSE_LIBGNOMEPRINT !wxUSE_GTKPRINT !SWIG
+# warning You must use '--with-gnomeprint' or '--with-gtkprint' in your wx library configuration for full print capabilities.
+# endif
+#endif
+#endif
+
/**
* Global variables definitions.
*
=== modified file 'common/edaappl.cpp'
--- old/common/edaappl.cpp 2013-01-30 17:15:45.08200 +0100
+++ new/common/edaappl.cpp 2014-02-10 08:30:18.555606190 +0100
@@ -451,7 +451,7 @@ bool EDA_APP::SetBinDir()
// Linux and Unix
#elif defined(__UNIX__)
-m_BinDir = wxStandardPaths().GetExecutablePath();
+m_BinDir = wxStandardPaths::Get().GetExecutablePath();
#else
m_BinDir = argv[0];
#endif // __UNIX__
=== modified file 'include/common.h'
--- old/include/common.h 2013-03-30 13:54:49.36700 +0100
+++ new/include/common.h 2014-02-10 08:48:03.118929397 +0100
@@ -42,16 +42,6 @@
#include convert_to_biu.h
#include colors.h
-#if !wxUSE_PRINTING_ARCHITECTURE !SWIG
-# error You must use '--enable-printarch' in your wx library configuration.
-#endif
-
-#if defined( __WXGTK__ )
-# if !wxUSE_LIBGNOMEPRINT !wxUSE_GTKPRINT !SWIG
-# error You must use '--with-gnomeprint' or '--with-gtkprint' in your wx library configuration.
-# endif
-#endif
-
class wxAboutDialogInfo;
=== modified file 'pcbnew/footprint_wizard_frame.cpp'
--- old/pcbnew/footprint_wizard_frame.cpp 2013-01-12 18:32:24.908999000 +0100
+++ new/pcbnew/footprint_wizard_frame.cpp 2014-02-10 08:37:33.975602049 +0100
@@ -77,9 +77,19 @@ BEGIN_EVENT_TABLE( FOOTPRINT_WIZARD_FRAM
EVT_TOOL( ID_FOOTPRINT_WIZARD_SHOW_3D_VIEW,
FOOTPRINT_WIZARD_FRAME::Show3D_Frame )
-/* listbox events */
+// listbox events
EVT_LISTBOX( ID_FOOTPRINT_WIZARD_PAGE_LIST, FOOTPRINT_WIZARD_FRAME::ClickOnPageList )
-EVT_GRID_CMD_CELL_CHANGE( ID_FOOTPRINT_WIZARD_PARAMETER_LIST, FOOTPRINT_WIZARD_FRAME::ParametersUpdated )
+
+#if wxCHECK_VERSION( 3, 0, 0 )
+EVT_GRID_CMD_CELL_CHANGED( ID_FOOTPRINT_WIZARD_PARAMETER_LIST,
+ FOOTPRINT_WIZARD_FRAME::ParametersUpdated )
+#else
+EVT_GRID_CMD_CELL_CHANGE( ID_FOOTPRINT_WIZARD_PARAMETER_LIST,
+ FOOTPRINT_WIZARD_FRAME::ParametersUpdated )
+#endif
+
+EVT_GRID_CMD_EDITOR_HIDDEN( ID_FOOTPRINT_WIZARD_PARAMETER_LIST,
+FOOTPRINT_WIZARD_FRAME::ParametersUpdated )
EVT_MENU( ID_SET_RELATIVE_OFFSET, FOOTPRINT_WIZARD_FRAME::OnSetRelativeOffset )
END_EVENT_TABLE()
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GLM update to 0.9.4.6
Hi Camille, GLM library used in KiCad, as you correctly assumed, is not patched. I have tested the patch under Linux and I did not encounter any difficulties. The decision to apply the patch is up to the main developers. Regards, Orson On 02/16/2014 11:37 PM, Camille 019 wrote: Here is the patch. -- Camille Date: Sun, 16 Feb 2014 11:03:08 -0500 Subject: Re: [Kicad-developers] GLM update to 0.9.4.6 From: chisophu...@gmail.com To: camille...@outlook.com CC: kicad-developers@lists.launchpad.net I think you forgot to attach the patch; I'm not seeing it on my end. -- Sean Silva ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Text in opengl
On 02/23/2014 09:59 AM, Lorenzo Marcantonio wrote: I really find ugly/distracting the messy line width in text in the opengl view, so investigated the thing... At the moment it generates the endpoint list and draw it thru the GAL DrawPolyline function. This substantially convert the line to a polygon to rasterize it with round endcaps, getting bluntly rounded by the transformation/projection matrices. I agree that's the right way to draw tracks and similar things. It also seems to me that the line is drawn with a fragment shader using a technique like that used for the circle (I never used shaders and I'm a bit confused... the comments talk about a *vertex* shader? AFAIK they aren't even supported on the Intel-Tungsten...) Truly they are. Vertex shaders are said to be supported since OpenGL 2.0, so fortunately most of current GPUs are compatible. In the process it pumps quite a bit of vertices (I'd say about 12 for a single line segment, but maybe I'm wrong). You are right. I think text could be better drawn using the classic GL_LINE_STRIP primitive and glLineWidth for setting the width. In aliased mode these are guaranteed to produce uniform line widths, since simply generate parallel fragments. Truly, line width 1 are not guaranteed but I never seen a GPU not doing these... I do not want to discourage you, but I am somehow sure that after deploying the code, you will find at least a few combinations of GPU/driver (most likely open)/OS that support only 1 pixel wide lines. Also this would pump only 1-2 vertices for line and, given how much text there is on a board with netlist name shown, should be quite a performance improvement. On a medium sized board I see: 09:50:25: Debug: RecacheAllItems::immediately: 1 1605,7 ms 09:50:25: Debug: Uploading 2097152 vertices to GPU / 62,8 ms When showing netnames and pad numbers. Disabling them I have: 09:51:02: Debug: RecacheAllItems::immediately: 1 1091,1 ms 09:51:02: Debug: Uploading 1048576 vertices to GPU / 35,3 ms That would need adding a DrawSimplePolyline member to the GAL layer doing the different draw processing. The bad side would be that this would apply even to copper text; I don't think the difference will be significant (since it's visual only, anyway)... if really wanted to maintain the 'precision' off copper text a flag could be added to the text function. What do you think of that? Have I missed something crucially important? Assuming that *every* card supports lines wider than 1 pixel, you are still limited to available line width range. In my case (integrated Intel GPU), http://pastebin.com/86jqj2bV outputs: line width range: 1.00 - 5.00 line granularity: 0.50 I am afraid you will not get much more on better video cards. As transformations do not apply to line width, you can have up to 5 pixel wide lines (at least in my case). This may be a problem for copper texts (as you rather expect them to apply to WYSIWYG), but should not be a limitation for netnames (depends on sight quality). Currently, OpenGL GAL makes use of VBOs. Most of static data (e.g. tracks, vias) are cached in GPU memory and to draw them you only send vertex indices. Dynamic data (e.g. preview, selection box, other temporary drawings) is collected and sent in one batch. Only grid and compositing (draw a few textured quads) are done using direct mode. It leads to 2 options: - Handling a VBO for line strips (and probably a shader or some other way of controlling line width per line, not for the whole batch). I am not sure if degenerated vertices (i.e. two consecutives vertices with the same coordinates to indicate beginning of a new line) work in GL_LINE_STRIP mode, otherwise you have to use GL_LINE instead. - Drawing using direct mode, but in this case all lines should be drawn at the same time. Also I wonder how does it compete with current VBO batch in terms of performance. If I had to choose, I would go for bitmap fonts. It makes every character one quad or two triangles. Or maybe antialiasing could solve the problem? Regards, Orson PS: for the XXX todo comments in the following bezier curves I'd recommend the de Casteljau algorithm (which seems to be the current standard for drawing them). Too bad they deprecated evaluators in newer OpenGL, if hw accelerated like in the old FireGL they would be *the* solution, here. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Text in opengl
On 02/23/2014 05:19 PM, Lorenzo Marcantonio wrote: On Sun, Feb 23, 2014 at 01:30:47PM +0200, Vesa Solonen wrote: Just check blending and transparency works well enough. The specs explicitly says that a fragment is generated for each rasterized 'pixel' (quoted since pixel is not a concept in opengl:P) so there shouldn't be problems with that. I find strange that the text engine was reimplemented from scratch since the drawtxt can happily works with a callback; whatever... I'm more concerned about the complications from state tracking in the GAL (i.e. having to pass and set everything correctly). It needs more study. I am here to help, do not hesitate to ask any questions. If you try to add new features to GAL and it does not work - let me know. Tidiness and legibility apart, the performance is worrying me since for a not-so-busy four layer board the time exceeds often 5 seconds; I guess that time is only CPU dependant (the GPU is probably only running 'after' that and even on Tungstens performance seems quite good). Unfortunately, recaching is done by CPU, that is the reason. To be able to simply pass vertex indices to render, those have to be precomputed earlier. All the transformations that used to happen in the fixed OpenGL pipeline are calculated by CPU now. Too bad this recaching thing is impacting even the standard view (it rebuilds when you toggle zone visibility so it isn't 'snappy' as before). Still quite acceptable, anyway. I guess it could be solved by just informing VIEW that items need to be recached and then do it when it becomes active. I will probably add it to the next merge request. Regards, Orson Given that's in it's infancy I'd assume there is still a huge gain for further (subsequent) optimization, I'm not too worried. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Text in opengl
On 02/24/2014 08:45 AM, Lorenzo Marcantonio wrote: - Handling a VBO for line strips (and probably a shader or some other way of controlling line width per line, not for the whole batch). I am not sure if degenerated vertices (i.e. two consecutives vertices with the same coordinates to indicate beginning of a new line) work in GL_LINE_STRIP mode, otherwise you have to use GL_LINE instead. Text should never generate identical vertices, otherwise font data is misoptimized :P anyway I don't remember seeing something forbidding them (but also nothing guaranteeing... so maybe they are implementation dependant - as usual!) It is not that text should generate identical vertices, the purpose is to separate lines stored in a single VBO. If you have a VBO drawn as GL_LINE_STRIP, then you will have *all* vertices drawn as a single continous line, so you need a way to tell GPU that there should be a break. It is better explained here (for triangles), chapter Use Triangle Strips to Batch Vertex Data: https://developer.apple.com/library/ios/DOCUMENTATION/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html Using a shader to fix line width should work, but doesn't reduce vertex count. I hoped to do that. Also I have no idea on how shaders work :P - Drawing using direct mode, but in this case all lines should be drawn at the same time. Also I wonder how does it compete with current VBO batch in terms of performance. If I had to choose, I would go for bitmap fonts. It makes every character one quad or two triangles. Or maybe antialiasing could solve the problem? Texturing the font would need a) a huge amount of texture memory (and Intels are sharing the system memory) and b) losing crispness due to resampling; I'd prefer the current situation in that case :D a) Why do you think so? It is just one black white texture containing all characters (e.g. http://i.stack.imgur.com/VFKM2.gif) and then it is simply referred to when drawing characters. Textures can also be colorized, so the bitmap black white is perfectly fine. b) Maybe there are some ways to sharpen textures, but I am not very familiar with the topic. Antialiasing on lines is historically never been implemented on consumer cards (it was one of the 'differences' of the Quadros), but maybe now the situation is different. In fact the FireGL we used (still the IBM design, not the overpowered Radeon) had the 'line' primitives (evaluators included) completely done in HW, antialiasing and stuff. But only one texture stage :D But for lines made from triangles it works http://oi58.tinypic.com/21n2s1j.jpg (yup, it is buggy, there is something wrong and currently I do not know how to fix it). Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Text in opengl
On 02/24/2014 11:43 AM, Lorenzo Marcantonio wrote: a) Why do you think so? It is just one black white texture containing all characters (e.g. http://i.stack.imgur.com/VFKM2.gif) and then it is simply referred to when drawing characters. Textures can also be colorized, so the bitmap black white is perfectly fine. How many characters? The full BMP, maybe (since we have unicode...); It's not *so* easy. Need thinking. Here it comes: http://unifoundry.com/unifont.html It takes ~2MB of memory and has size of 4128x4160 px, so there is a chance that it could fit to 4096x4096 if the frame is cropped. The bad thing is that it may look really ugly if characters are too much stretched. On the other hand, I suppose that naming nets using non-ascii characters is a rare case (however it has to be supported if that is the policy). Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Drawing tools for GAL
Hi Carl, Thanks for the report. As the error does not occur on every PCB, please send me the file that crashes pcbnew - I would like to investigate the problem further. Does it happen regularly or was it a single case? Regards, Orson On 03/08/2014 07:35 PM, Carl Poirier wrote: Great news! This morning I built the branch to test it out. I loaded some existing board, switched to OpenGL mode and tried to place a track on a random spot. Moving the mouse around to draw the track rapidly creates an error. I have no idea if it's related to the new tools, as I haven't played much yet with the OpenGL rendering, but anyway here it is: kiRound_: in file /home/thesmith/kicad/drawing_tool/pcbnew/pcb_plot_params.cpp on line 349, val: 1000.5 too ' 0 ' for int Segmentation fault (core dumped) If you need the .kicad_pcb file I can send it to you. If you simply need more information, please kindly explain me how to get it and I'll be happy to debug more. Carl On Sat, Mar 8, 2014 at 9:49 AM, Alberto Medrano ing.a...@gmail.com mailto:ing.a...@gmail.com wrote: Awesome! Alberto On 03/08/2014 09:26 AM, Maciej Sumiński wrote: Ladies and gentlemen, This time our branch [lp:~cern-kicad/kicad/drawing_tool] brings some drawing tools to the GAL canvas in pcbnew. The most important changes: - tools are bound to the respective buttons on the right toolbar (there is no Selection tool or Interactive router entry in menu) - new tools make possible to draw zones, lines, circles, arcs (the last one is a improved a bit; '/' changes the direction of arc) and place modules, texts, dimensions and targets - you can change the line width while drawing (using -/+ keys) - by default you can draw lines/zones at any angle; to enable 45 degree mode (resembling push and shove router) you may hold Ctrl while drawing - after selecting a single graphical item, you will see edit points that allow you to modify vertices by dragging them; it also supports 45 degree mode activated by holding Ctrl You may have a look on a short demo presenting the mentioned features: https://vimeo.com/88430298 (or even better - build the branch and test it yourself). Next features in the plan: - edit points for dimensions - drawing drc markers - updating coordinates displayed on the statusbar (cursor position) - support for some missing hot keys (e.g. zoom in/out, changing layers) - configuration dialog menus for the Push Shove router - fix a number of places where pcb is updated in the default canvas, but the GAL canvas had to be switch back and forth to show the changes Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp -- Alberto Medrano Telf: 0416 681 3010 ++ CONFIDENTIALITY NOTICE ++ This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Este correo electrónico puede contener información confidencial y/o privilegiada. Si usted no es el destinatario previsto (o ha recibido este correo electrónico por error), por favor notifique inmediatamente al remitente y borre éste e-mail. Cualquier copia no autorizada, divulgación o distribución del material en este correo electrónico está estrictamente prohibida. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net
Re: [Kicad-developers] Drawing tools for GAL
On 03/10/2014 08:32 PM, jp charras wrote: Le 10/03/2014 08:43, Maciej Sumiński a écrit : Hi Carl, Thanks for the report. As the error does not occur on every PCB, please send me the file that crashes pcbnew - I would like to investigate the problem further. Does it happen regularly or was it a single case? Regards, Orson Thanks, Orson. I can't reproduce this issue, but I have some others -both on Window and Linux): - when opengl is on, moving a footprint (m command), and then cancel the move (escape command) crashes pcbnew. - I can't compile the automatically created pcbnew_wrap.cxx with KICAD_SCRIPTING=ON This is also true for ~cern-kicad/kicad/netnames branch, so i am thinking ~cern-kicad/kicad/drawing_tool already uses netnames changes (which does not create any serious issue, but python compatibility) Other issues, but not related to this kicad branch: - An issue in PS router: it allows tracks between not connected pads (i.e. netcode = 0) - and other issue: PS router does not know the board edges. - Ratsnet issue: when opengl is on, there is an issue relative to the ratsnest which does not detect some connections made by copper zones, and shows (erroneously) some missing connections (for instance in the demo pic_programmer shows this issue) Great work! Thank you for reporting the issues. It seems that the branch still needs some work before it is fully usable. I will fix the problems as soon as possible. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Drawing tools for GAL
On 03/10/2014 08:32 PM, jp charras wrote: (...) I can't reproduce this issue, but I have some others -both on Window and Linux): - when opengl is on, moving a footprint (m command), and then cancel the move (escape command) crashes pcbnew. Should be already fixed in the branch. - I can't compile the automatically created pcbnew_wrap.cxx with KICAD_SCRIPTING=ON This is also true for ~cern-kicad/kicad/netnames branch, so i am thinking ~cern-kicad/kicad/drawing_tool already uses netnames changes (which does not create any serious issue, but python compatibility) Currently it is workarounded. The problem is caused by the fact that SWIG does not support nested classes, so right now erroneous parts are surrounded with #ifndef SWIG..#endif. There is another solution suggested by the SWIG documentation (http://www.swig.org/Doc1.3/SWIGPlus.html#SWIGPlus_nested_classes), but it seems even worse to me. (...) - Ratsnet issue: when opengl is on, there is an issue relative to the ratsnest which does not detect some connections made by copper zones, and shows (erroneously) some missing connections (for instance in the demo pic_programmer shows this issue) I was not able to reproduce the bug (tried out a few boards in the demo folder, including pic_programmer). I loaded a file, switched canvas a few times, moved modules from their default location and back and I could not notice any wrong ratsnest line. Could you post a screenshot, so I know to which places should I put more attention? Does it occur right after a file is loaded or do you perform some editing first? Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Help to solve a bug - bug #1227500
Hi José, That is great that you are willing to help. I am sure that if you manage to fix the bug, many users will be grateful for that. The faulty line is pcbnew/pad_edition_functions.cpp:113, it resets the offset settings. The question is: is it intended or just a mistake? Regards, Orson On 03/20/2014 12:44 AM, José Eduardo S. C. Xavier wrote: Hello, Today I was design a part and found a important bug on the pcbnew. If you export settings from one pad and apply using new pad settings to other pad the offset and clearance value isn't applied. https://bugs.launchpad.net/kicad/+bug/1227500 I have some background on C/C++ and software development but the project is a little big to me, can you help to know where should I start to fix that bug? Thank you ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] why do I see this every time I load a working BOARD file?
On 04/04/2014 06:08 PM, Lorenzo Marcantonio wrote: On Fri, Apr 04, 2014 at 08:37:05AM -0500, Dick Hollenbeck wrote: Is there something wrong with my BOARD? If so, what? AFAIK they appeared with the CERN router merge... they said it was something like unsupported pad configurations (like a soldermask only pad and stuff). Seems harmless but I agree it's somewhat annoying... Sincerely, I do not recall saying anything like this. If I am not mistaken, I have seen this since I started KiCad development (or at least for a veeery long time) and at first I was also wondering if there is something wrong. For sure we are not authors of this assert. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] KiCad GAL upgrades
Ladies and gentlemen,
As it was recently promised, we have fixed many bugs and added some new
features to the GAL canvas in pcbnew (branch
lp:~cern-kicad/kicad/drawing_tool).
Main changes include:
- edit points for dimensions
- zones got a new edit mode (I call it 'keep side slope', you can see
demo in the video below) - try dragging zone sides with Ctrl pressed, it
changes length of sides, but their slope is preserved
- double click on a zone side creates a new edit point
- drc markers are drawn (if you run them when GAL is active; yet there
is a minor bug - you need to refresh view to see them, soon to be fixed)
- net highlighting (hold Ctrl and click a track/pad/via/zone;
highlighting using the toolbar button does not work yet, sorry)
- current cursor coordinates are updated on the bottom statusbar
- most of the default hotkeys are already working, I added shortcuts for
changing track width ([]) and via size ('\)
- importing netlists, global deletions board cleanup effects are
instantly visible in the GAL canvas, no need to toggle canvases anymore
- tools can be invoked using menu
You can watch a demo presenting some of above features here:
https://vimeo.com/90995942 (still uploads, should be available soon)
I know that many of you keep asking about a new Push and Shove router
release - we are getting close to it. If you are curious about the
upcoming changes, there is a blueprint [1] prepared by Tom. To tell the
truth, I really look forward to merging all that goodies.
Regards,
Orson
[1] http://www.ohwr.org/attachments/2792/pns_blueprint.pdf
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] constness of HitTest(const wxPoint)
On 05/02/2014 03:43 PM, Lorenzo Marcantonio wrote: (...) I think the design issue is that the zone has the selected part as an internal state, but I reckon that would be very difficult to fix (I have no better place to store it, at the moment, especially during edit): the problem is that a zone is a composite object, so m_CurrentItem is not enough to address it. But, for example, MoveEdge could have the edge passed as an argument instead of using object state (would you use a string class with only embedded pointers and no positions in member calls?) Hi Lorenzo, With the new tool framework, the currently modified part of zone (be it corner or edge) is stored internally in the tool that does the modification (pcbnew/tools/point_editor.cpp in lp:~cern-kicad/kicad/drawing_tool). To be more precise - while editing, you modify location of EDIT_POINTs and when you stop dragging, zone corners are updated. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Forward-compatibility in s-expression formats
On 05/09/2014 08:44 PM, John Beard wrote: Is there existing infrastructure for benchmarking, for example any used when designing the current parser? It was not used for when designing the current parser, but you may find useful include/profile.h. Have a look at common/view/view.cpp for an example of usage (search for 'prof_counter'). Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Commit Rights to Orson
On 05/10/2014 05:44 AM, Dick Hollenbeck wrote: Orson has earned commit rights to product branch. Thank you Dick, I feel honoured by your decision. I promise to use it for a good purpose. Now I have a reason to celebrate this evening too. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Push and Shove not working anymore? (since today, was working yesterday)
Hi Edwin, Now the Push and Shove router has much more options than before. I suppose that you are using Walkaround mode. To change it, you may either click right mouse button or press 'E' while the router is active. Regards, Orson On 05/19/2014 10:52 PM, Edwin van den Oetelaar wrote: Some details about my build : Application: pcbnew Version: (2014-05-19 BZR 4872)-product Release build wxWidgets: Version 3.1.0 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.6.3,wx containers,compatible with 2.8) Platform: Linux 3.2.0-60-generic x86_64, 64 bit, Little endian, wxGTK Boost version: 1.54.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=OFF KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON On Mon, May 19, 2014 at 10:51 PM, Edwin van den Oetelaar oetelaar.automatiser...@gmail.com mailto:oetelaar.automatiser...@gmail.com wrote: Hello everyone, It looks like something was broken today. Yesterday the push and shove was working when using OpenGL view. It was integrated, using the normal 'Add tracks and via's' button. Today, adding tracks works, but they do not push away the other tracks anymore. Maybe some error on my part but maybe someone else is having this problem too? Greetings, Edwin van den Oetelaar ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GAL for non-OpenGL
Hi Lorenzo, On 05/23/2014 09:33 AM, Lorenzo Marcantonio wrote: I was reading the road map (good work on that BTW), and I would comment on this point: - Port wxDC to GAL or get Cairo rendering to nearly the performance of the current wxDC rendering so that we have a single framework to develop new tools and we can continue to support systems that don't have a complete OpenGL stack. Question: why not simply do a GAL implementation using wxDC instead of the other way? Are there technical issues on that? It is exactly the way how we would like to have it done - develop another rendering backend using wxDC (and then if there is some spare time available - aalib). Also I don't know why but it seems that the opengl view is more tiring on the sight... maybe it's because it's less contrasty or because of the transparent blending? no idea, just an impression of mine (I've really thick glasses so I'm not a 'standard' viewer) Try experimenting with color settings. There are (unoffical yet) hot keys for changing transparency of the active layer (shift+[ shift+]) - maybe that can help a bit. Personally, I think that antialiasing could make a difference too (have a look at the Cairo backend). Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Blueprint for Unified Rendering Framework
On 05/23/2014 03:03 PM, Wayne Stambaugh wrote: On 5/21/2014 4:44 AM, Maciej Sumiński wrote: I would like to present you a new blueprint on the subject of unification of canvases and improvements to the module editor in pcbnew: https://blueprints.launchpad.net/kicad/+spec/module-editor The blueprint is one of the last phases of pcbnew conversion to the new view component (aka GAL), described in Unified Rendering Framework work package in the official KiCad road map. Please feel free to comment, we are open to discussion. Regards, Orson, CERN Orson, I noticed that you included an alignment tool. Is this tool only available in the footprint editor? I would find an alignment tool equally useful in the board editor. I'm guessing that the tools are reusable so it should not be too difficult to add the alignment tool to the board editor. Everything else looks great. Cheers, Wayne Hi Wayne, Thank you for the feedback. I cannot agree more, I had the same idea about the alignment tool. I think it will not be a big effort to have it in both places, so you can expect the functionality in the board layout editor as well. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Website update
Hi, I have seen users having problems compiling KiCad under Mac OS X as a result of using an inappropriate method, i.e. running KiCadOSXBuilder which is not maintained anymore instead of the constantly improved way of cmake make. Therefore I think Mac OS users would be much happier if they were pointed to the right instructions (http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/Documentation/compiling/mac-osx.txt) on the official website. Is there anyone who has modification access to the website and is willing to change that? Thank you in advance, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Copper layer count
On 06/06/2014 07:58 PM, Lorenzo Marcantonio wrote: On Fri, Jun 06, 2014 at 07:50:50PM +0200, jp charras wrote: I am pretty sure this is a very old legacy code. It is now allowed. If it's allowed then no issue at all. It made me curious since the layer setup dialog doesn't allow it (and once I tried to do a one layer board and I searched for it). Actually it's very new code. PCBNEW_CONTROL::LayerPrev, for the new GAL interface. Maybe he's simply been cautious. It was taken from pcbnew/hotkeys_board_editor.cpp:243. I assumed that if it is checked there, then there is a reason for that. Good that there are vigilant code reviewers here, thank you. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Static variables in module editor
Hi,
I have found a few static variables in the module editor code that I
would like to remove, but I need to know your opinion. The variables are
used to keep the last edited module between editor invocations.
If we want to preserve such behaviour, I will need to add a few more
static variables (for sure VIEW, maybe VIEW_CONTROLS and some stuff
related to the Tool Framework). I would rather avoid such solution.
Furthermore, the footprint stored in the editor is completely
independent - it is not bound to anything on board or library. Do we
need to keep it? If there is a modification done, the user is asked if
he wants to save his work or update a footprint, so there is a little
chance of losing data.
The attached patch will give you an idea of proposed changes.
Regards,
Orson
From b34bac092cbb63fef2182400a43dd34c2a43fcf6 Mon Sep 17 00:00:00 2001
From: Maciej Suminski maciej.sumin...@cern.ch
Date: Tue, 10 Jun 2014 09:41:42 +0200
Subject: [PATCH] Removed static BOARD PCB_SCREEN from module editor.
---
pcbnew/module_editor_frame.h | 1 -
pcbnew/moduleframe.cpp | 28 +---
2 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/pcbnew/module_editor_frame.h b/pcbnew/module_editor_frame.h
index 0bc942f..8f54bae 100644
--- a/pcbnew/module_editor_frame.h
+++ b/pcbnew/module_editor_frame.h
@@ -408,7 +408,6 @@ protected:
/// protected so only friend PCB::IFACE::CreateWindow() can act as sole factory.
FOOTPRINT_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent );
-static BOARD* s_Pcb; /// retain board across invocations of module editor
/**
* Function GetComponentFromUndoList
diff --git a/pcbnew/moduleframe.cpp b/pcbnew/moduleframe.cpp
index 913ee70..7fd0273 100644
--- a/pcbnew/moduleframe.cpp
+++ b/pcbnew/moduleframe.cpp
@@ -62,10 +62,6 @@
#include tools/common_actions.h
-static PCB_SCREEN* s_screenModule; // the PCB_SCREEN used by the footprint editor
-
-BOARD* FOOTPRINT_EDIT_FRAME::s_Pcb;
-
BEGIN_EVENT_TABLE( FOOTPRINT_EDIT_FRAME, PCB_BASE_FRAME )
EVT_MENU_RANGE( ID_POPUP_PCB_ITEM_SELECTION_START, ID_POPUP_PCB_ITEM_SELECTION_END,
PCB_BASE_FRAME::ProcessItemSelection )
@@ -186,20 +182,15 @@ FOOTPRINT_EDIT_FRAME::FOOTPRINT_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent ) :
drawFrame-GetGalCanvas()-GetBackend() );
SetGalCanvas( drawPanel );
-if( !s_Pcb )
-{
-s_Pcb = new BOARD();
+m_Pcb = new BOARD();
-// Ensure all layers and items are visible:
-s_Pcb-SetVisibleAlls();
-}
+// Ensure all layers and items are visible:
+m_Pcb-SetVisibleAlls();
-SetBoard( s_Pcb );
+SetBoard( m_Pcb );
-if( !s_screenModule )
-s_screenModule = new PCB_SCREEN( GetPageSettings().GetSizeIU() );
-SetScreen( s_screenModule );
+SetScreen( new PCB_SCREEN( GetPageSettings().GetSizeIU() ) );
GetScreen()-SetCurItem( NULL );
LoadSettings( config() );
@@ -286,15 +277,6 @@ FOOTPRINT_EDIT_FRAME::FOOTPRINT_EDIT_FRAME( KIWAY* aKiway, wxWindow* aParent ) :
FOOTPRINT_EDIT_FRAME::~FOOTPRINT_EDIT_FRAME()
{
-// When user reopens the Footprint editor, user would like to find the last edited item.
-// Do not delete PCB_SCREEN (by the destructor of EDA_DRAW_FRAME)
-SetScreen( NULL );
-
-// Do not allow PCB_BASE_FRAME::~PCB_BASE_FRAME()
-// to delete our precious BOARD, which is also in static FOOTPRINT_EDIT_FRAME::s_Pcb.
-// That function, PCB_BASE_FRAME::~PCB_BASE_FRAME(), runs immediately next
-// as we return from here.
-m_Pcb = 0;
}
--
1.9.1
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 10:26 AM, Lorenzo Marcantonio wrote: On Tue, Jun 10, 2014 at 10:18:57AM +0200, Maciej Sumiński wrote: Hi, I have found a few static variables in the module editor code that I would like to remove, but I need to know your opinion. The variables are used to keep the last edited module between editor invocations. Ah these. I stumbled in them, too... the 'default' thing in pcbnew often works only the first time, until you confirm something; after that, it becomes the new default. Example, text size: default text size is saved in the ini file from the settings and it's used the first time you add text. However when you edit the text side of an object, *that* becomes the new default until you restart pcbnew or edit another object. So it's default until I have another value picked as default. Curious but it actually works well. I see the point of keeping last settings, but should the footprint become a new default too? It is much more than e.g. text size, which is common for many instances. If we want to preserve such behaviour, I will need to add a few more static variables (for sure VIEW, maybe VIEW_CONTROLS and some stuff related to the Tool Framework). I would rather avoid such solution. For the OO purists statics are Evil. YMMV. For the current behaviour I think they are the best solution. Given that we want to preserve the behaviour - I do not see any other sensible solution at the moment. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Static variables in module editor
On 06/10/2014 06:02 PM, Dick Hollenbeck wrote: The attached patch will give you an idea of proposed changes. Regards, Orson We can kill two birds with one stone here. I like your changes, but they are insufficient to preserve the current behaviour. With a little bit of work we can accomplish a couple of useful things. I think we need to save that footprint in the PROJECT. Maybe put it there upon wxFrame destruction, and go get it upon wxFrame creation. That makes it project specific. I plan on renaming the PROJECT::RPath() infrastructure to RString(). That is it will hold wxStrings instead of the goofy RETAINED_PATH. What is now RETAINED_PATH can also go into the RString() holder. enum RETPATH_T becomes RETSTRING_T. : I can do the RString() change in the next half day, and it's something I intended to do anyways. Orson, this set of changes had to happen anyways as we moved to multiple open projects, so I welcome your help and cooperation. I committed class PROJECT::GetRString() and SetRString() in rev. 4934, paving the way for saving the MODULE in a session and project specific location and retaining the current UI behaviour, while clearing some of the clutter in the path of multiple open projects. Hi Dick, I agree with Lorenzo and Tom - I prefer the module editor to start either empty or with a footprint loaded from library or board, without storing anything inside. How often does it happen to you to make use of the feature? I guess the module editor is primarily invoked to either modify a specific footprint from a board/library or to create a new one. However, I strongly believe we need to cooperate. Sometimes it leads to a compromise, but the final decision is particularly crucial if other main developers agree on the subject. Wayne, Jean-Pierre - I am willing to hear your opinion on the topic. Given everyone shares the view, then having a choice between adding more static fields to the module editor or the above solution, I pick your proposal. Thank you for the advices and the groundwork that will definitely ease the task. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Module classes refactorization
As I have already most of the tools adopted to work with module editor, I have a few suggestions that may result in cleaner and more generic code. They require a bit of changes in the internals of KiCad, therefore I prefer to ask for your input before I proceed. I am not sure if the efforts are worth it - if there is half of KiCad code to be ripped out, then I will leave it up to the moment when GAL Tool Framework are mature enough to become the main interface. I will be able to tell more when I start digging through the code, if the ideas get acceptation. 1) Change MODULE-specific structures (TEXTE_MODULE, EDGE_MODULE) to have a common interface for position control. The main difference between module and non-module version is the module type store two types of coordinates: relative (to parent module) and absolute. The developer is forced to synchronize them if one of them changes, because there are separate methods to access them. I propose to drop the relative position field and modify the methods to compute relative position on the spot. That makes one step closer to simplifying the class tree that probably could live without the MODULE flavoured classes, but I do not dare to propose it right now. For the time being I would make TEXTE_MODULE inherit from TEXTE_PCB. This way they are no longer parallel in hierarchy and offer a common interface to be used by the tools. 2) Unify the way undo buffer works in the layout and module editors. There is a special undo operation type for the module editor (UR_MODEDIT) that saves the entire edited module. Such entry has to be created before any modifications are done, in contrary to other undo operation types that are stored afterwards. I believe the module editor could work in the same manner as the layout editor and UR_MODEDIT could be disposed. 3) Create an abstract class BOARD_CONTAINER. The class will contain 3 pure virtual methods, that have the same purpose as in the BOARD class: - void Add( BOARD_ITEM* aItem[, bool aAppend] ) - BOARD_ITEM* Remove( BOARD_ITEM* aItem ) - void Delete( BOARD_ITEM* aItem ) If BOARD and MODULE classes implement the BOARD_CONTAINER interface, tools may add/remove items without testing if it is a board or module. I look forward to hearing from you. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Module editor upgrade
Ladies and gentlemen, We have just reached the next step of our development plan. We would like to offer you a refurbished module editor, extended with the GAL and the Tool Framework. Besides the new graphic engine, you will find there: - layer widget - to select the drawing layer before you start creating graphics (including Edge.Cuts layer) - drawing tools - already known from the layout editor (draggable items, point editor, line splitting, etc.) - copy and paste using reference points - feel the power of instant replication - align/distribute - to save you some time on precise mouse movements - pad enumeration tool - that is the missing piece in the lightning fast footprint creation process - DXF import - we do not blame you if you prefer other graphic utils (it is possible mostly due to efforts of Jean-Pierre Charras, the main author of DXF import code) We invite you to watch a short video, in which you may see the new features in action. To give you an example, there is a part on how to draw a QFN64 footprint in less than 2 minutes: https://vimeo.com/99235812 The code is available for testing in the repository: https://code.launchpad.net/~cern-kicad/kicad/module_editor After a period of testing, it will be merged to the product branch. You may help shortening the time by letting us know if everything works as expected. I feel obliged to say thank you to the KiCad community that gave us a few thoughts regarding improvements. We should ask you more often, you have great ideas. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Module editor upgrade
Hi Jon, I cannot recreate the bug, do you mind adding some details? Does it happen every time? If not, are there any repeatable steps to reproduce the error? Does it crash afterwards or you are still able to edit the footpritn? Did you edit an existing module or created a new one? Which wxWidgets version do you use? By the way, the segmentation fault when pcbnew is run from the launcher should be already fixed. Regards, Orson On 07/01/2014 05:16 AM, Jon Neal wrote: I also get a segfault when trying to open the module editor from a pcbnew spawned from kicad, but not from a standalone pcbnew. From the standalone pcbnew instance I placed a single pad and when I right clicked and tried to open properties the window popped up and was blank white and a blank error box appeared as well. On Fri, Jun 27, 2014 at 5:45 PM, Nick Østergaard oe.n...@gmail.com wrote: Hi Orson The video ĺooks nice. :) I just tried to build it today, but it failed when I enabled the sripting. I don't know if you have tested that yourself, so I won't tell the details now. I did manage to build without scripting, but there are some segfaults. But I get no segfault by just switching to opengl. I get a segfault if I start pcbnew from the kicad app on a project. But if I open pcbnew directly it do not segfault and I am able to go to opengl and open the module editor just fine. But running from the kicad app, I get another bt compared to Kaspar, I have attached it. I happend when I hit the icon for the module editor in the top toolbar. Version: (2014-06-26 BZR 5056)-module_editor Release build wxWidgets: Version 3.0.1 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.9.0,STL containers,compatible with 2.8) Platform: Linux 3.15.1-1-ARCH x86_64, 64 bit, Little endian, wxGTK Boost version: 1.55.0 USE_WX_GRAPHICS_CONTEXT=OFF USE_WX_OVERLAY=OFF KICAD_SCRIPTING=OFF KICAD_SCRIPTING_MODULES=OFF KICAD_SCRIPTING_WXPYTHON=OFF USE_FP_LIB_TABLE=HARD_CODED_ON BUILD_GITHUB_PLUGIN=ON 2014-06-26 15:58 GMT+02:00 Maciej Sumiński maciej.sumin...@cern.ch: Ladies and gentlemen, We have just reached the next step of our development plan. We would like to offer you a refurbished module editor, extended with the GAL and the Tool Framework. Besides the new graphic engine, you will find there: - layer widget - to select the drawing layer before you start creating graphics (including Edge.Cuts layer) - drawing tools - already known from the layout editor (draggable items, point editor, line splitting, etc.) - copy and paste using reference points - feel the power of instant replication - align/distribute - to save you some time on precise mouse movements - pad enumeration tool - that is the missing piece in the lightning fast footprint creation process - DXF import - we do not blame you if you prefer other graphic utils (it is possible mostly due to efforts of Jean-Pierre Charras, the main author of DXF import code) We invite you to watch a short video, in which you may see the new features in action. To give you an example, there is a part on how to draw a QFN64 footprint in less than 2 minutes: https://vimeo.com/99235812 The code is available for testing in the repository: https://code.launchpad.net/~cern-kicad/kicad/module_editor After a period of testing, it will be merged to the product branch. You may help shortening the time by letting us know if everything works as expected. I feel obliged to say thank you to the KiCad community that gave us a few thoughts regarding improvements. We should ask you more often, you have great ideas. Regards, Orson ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
