I have read a few posts about this, but most ended about a year ago.
Ubuntu 20.04 install, kicad 5.1.5, after using kicad 4.
kicad 4 had the layer mixing where the colors merged when layers overlapped. now it seems the topmost layer is overlaid onto all of the other layers, and takes a very low opacity of the top layer to see what is underneath. So low of opacity that it makes figuring out where to route very hard to see for me.
the biggest issue with this is when traces mirror each other and a new via needs to be added, either to change layers or to allow connecting traces - especially on an 8+ layer setup.
With the myriad of colors when mixing in kicad 4, this was easily seen, and now it is an absolute pain to route multi-layer boards because every layer has to be cycled through for every via.
Even in the “high contrast” mode, there is no way to tell if a trace is under a current trace, or how far it extends, whereas in kicad 4 it was seamless.
If there is any way at all of bringing back layer mixing, that would be ideal.
If layer mixing isn’t possible, then make it possible to at least adjust the high contrast mode opacity to give a little bit of a better view of the other traces.
In the colour options of the layer, play around with opacity till you feel somehow comfortable.
Getting used to the opengl canvas takes a while but it pays off in the end.
There is much room for improvement here indeed.
The reason it was done is that the old way was a CPU intensive task, while the Opacity can be handled by the Video hardware and is therefore much faster.
I also find it annoying to set opacity below 80% because then the layer you are working on becomes too unclear for me.
I’ve blabbed about this a few times, even made some suggestions, about auto switching opacity of layers, and drawing the current layer 100% opaque and draw other layers over it with a very low opacity.
Another idea was to be able to pin a layer to the top, for example F.SilkS to keep orientation on the PCB.
But the truth is that I also do not know what would be a real good way to handle this, and I’ve never made a feature request for it.
I also do not make boards with more then 2 copper layers.
I have been reading forum posts for a while today trying to figure out how to make due, and it seems the opengl structure makes color mixing impossible, so opacity is the only answer.
I would like to restate that having an option to change the “high contrast” mode opacity would be nice, because then at least there wouldn’t be too much eyestrain to see all of the internal layers.
it’s no wonder x-ray vision is considered a superpower.
How do you do your 8 layer boards?
If it’s mostly in pairs of layers then you can turn most of the other copper layers off.
If it’s a mix and mash of switching between layers, you have more routing freedom, but I think it would drive me crazy.
I guess that if you come up with a well thought out set of rules that are also relatively easy to implement and work good with the Open GL framework it has a reasonable chance of being implemented in the near future if a feature request is made on Gitlab.
@jlend you can hit F9 and get the Legacy canvas with XOR color mixing.
But it is supposed to be abandoned in future KiCad revisions so it’s better to get used to OpenGL layering. I work at 80% transparency and it feels natural to me now, but I don’t work on more than 4 layers with my projects.
It would be interesting to know if it would be possible to have a new canvas, based on the non-accelarated Cairo canvas, and propagate that specific graphics calculation to the GPU (using OpenCL; see https://en.wikipedia.org/wiki/General-purpose_computing_on_graphics_processing_units). At least for me, an uninitiated but a bit technically oriented person, XORing colors sounds so simple task that the speedup could be e.g. 100x with modern Nvidia or AMD GPU hardware.
It depends on the complexity.
Sometimes hand routing is better than setting up rules.
Other times the boards need more more isolation but also need routing, so pairs don’t line up - top and bottom for routing, layer 1 for ground, but because power is very localized, it doesn’t need layer 7 to be all power, but then maybe layer 4 or 5 needs another ground plane, but the pair doesn’t need to be used, or needs to be routed - leaving an open layer.
As far as cpu usage, while I understand the idea that many different installs need to be targeted for any project, just how much cpu usage is this?
working on a 10 year old system is one thing - where I can expect things to slower and bog down, the newer systems in the last 5 years are all multicore at pretty high speeds. is there any data showing the tradeoff?
I’ve used legacy mode on my previous system - 16.04 with kicad 5.1.x, and could barely tell the difference between modern and legacy.
For some reason in Ubuntu 20.04, the install doesn’t have F9 as an option anymore. Same hardware, just installed the new OS along with kicad. F9 doesn’t show up as an option under “Preferences” and just pressing F9 doesn’t change the behavior.
I don’t know if that is an install issue between Ubuntu and kicad, or just a purely kicad issue.
The [F9] legacy toolset has also disapeared from my linux box for quite some time. half a year maybe longer. I stopped using the legacy toolset because the Interactive Router does not work with it, and found the Interactive router more important than the XOR view.
After a while I got used to it and forgot what the old toolset looked like. I think I switched about 2 years ago. I think the old toolset is expected to be completely phased out on all platforms.
I imagine that writing KiCad is an enourmous effort and pulling in another graphics library for just this function adds even more complexity. I think the way forward is to make the best we can with the libraries we have now, or a very carefull selection. Apple hates open source and has not maintained OpenGL for years and I think has abandoned it completely. I have no Idea how KiCad handles this, but apparently it works.
I also think that a lot can be done with just the order in which layers are drawn and auto switching of opacity. If you keep the current layer always at 100%, you can draw other layers over it with an opacity as low as 20%, or maybe even lower. Because the current layer (pair) is 100% opaque it stands out, and when other layers are drawn over it, you can still see them.
The way it works now by drawing the current layer on top of the others so it hides everything is sort of ridiculous. If you set the opacity of the current layer to a lower value then 80% it also starts becoming increasingly invisible, which induces fatigue.
To me it feels like a developer was working on this, and then halfway got distracted and left it in that state.
I appreciate the effort that goes into software, and especially of this magnitude. The version jump from 4 to 5 was probably an incredible amount of work too.
I haven’t kept up on the state of opengl, and hopefully there are still good maintainers keeping it afloat.
As with most things software, compromises need to be made, and learning takes time, which i will gladly learn with.
I just installed kicad 5.1.5_3 on windows, and legacy (F9) seems to still work with that. Might be that other factors are at play beyond just kicad.
But If I remember correctly, the Interactive router does not work in the F9 toolset. Is this correct? Does this mean you have no experience (yet) with the interactive router?
This promotional video from 2014 for the Interactive Router says you have to switch to OpenGL (@ 01:05) to make the Interactive router work:
Especially being able to push tracks and via’s aside to squeeze in just one more track or via is such a huge time saver.
After some time it very much changed my approach to routing. The interactive router has a mind of it’s own, but you can outsmart it and make it do a lot of things very easily which would have been very tedious before.
I have not worked with the interactive router yet. I might give it a go.
Another reason I like the merged color scheme is that i can follow traces from beginning to end pretty easily, so that if a trace is a high frequency or high power trace that might produce fields, I can be aware of that and keep more distance as needed.
I don’t doubt the benefits of the interactive router. Sometimes I like to keep control to understand the entire layout instead of having to go back and figure out what is happening. In many cases, I still don’t understand why I did something long ago - but it seems to work having to try to figure out and correct interactively routed traces might take longer.
I will spend more time on test projects learning the new methods.
thanks
If you want to test the Interactive router, do not do it with a “small test project”.
It shines most with complicated designs.
So make a copy of a (moderately) complex board to begin with, and then use: Pcbnew / Edit / Global Deletions to remove all tracks and vias.
KiCad uses Cairo 2D graphics library for the non-accelerated canvas.
OpenGL works on Mac. If it’s starting took like it doesn’t some day, the developers must come up with a strategy. Probably there will be a working compatibility layer for OpenGL on Mac. There’s no definitive answer to that generic problem which is of course about more than just KiCad, but it’s not a danger today or tomorrow.
OpenGL doesn’t have API for XORing for colors, it’s that simple. It’s not something which is needed in 3D graphics. There have been several mentions about that in some developer discussions, there’s no one definite authoritative discussion. The graphics hardware would of course be capable of doing that in one way or another, that’s why I suggests OpenCL as an alternative. I have no idea how difficult it would be to implement.
having to try to figure out and correct interactively routed traces might take longer.