Ahh, OK. It’s just that Backspace and Delete DO work while in track mode in Legacy. Which is nice, because you don’t have to exit out of it to delete things.
I may well have been in track mode when I tried it in OpenGL.
You can turn the clearance graphics off in the preferences.
That helps, but then makes it harder when routing near other traces, which don’t have a wireframe clearance outline like pads do.
I think being able to make the grey clearance graphic transparent or wireframe, as well as disabling it completely, would be better.
Please tell me what to put in the two lines of code below instead of DARKDARKGRAY. I can bet whatever you choose will make someone else angry 
gal->SetStrokeColor( COLOR4D( DARKDARKGRAY ) );
gal->SetFillColor( COLOR4D( DARKDARKGRAY ) );`
Certain editing functionality seems lost in OpenGL mode. I cannot delete track segments with delete key just by hovering over them. I can’t drag components and have the tracks auto-extend or shrink to follow.
Works for me both in selection and routing tool. Recent nightly here.
Not the best thing to do in my humble opinion But you can always hold Shift while routing to disable all snapping completely.
Tom
1 Like
Time to write a bugreport with the tag ‘wishlist’ and promoting it here, so it collects a couple ‘likes’ for the developers to appear on their radar at least.
1 Like
Sounds like ‘user can choose’ would be the way to go in that case?
Or is that one of those hardcoded one-of things, which there exists no framework for to make it user controllable?
In your video, you can pull the cursor to the grid you want with the pointer device. With my current version of KiCad the cursor does not follow the mouse, instead it follows the end of the trace of the interactive router.
I believe one of the bugs on launchpad is requesting for that color to follow transparency setting of the corresponding layer. It doesn’t have to be solid grey.
1 Like
I’m gonna have to call that one… XORing the layers should be mind bogglingly simple for modern GPU hardware. Any GPU from the last 20 years can probably do this in hardware. Even most later fixed function GPUs can probably do this with relative ease.
That said transparency that KiCad currently uses is very inferior to the old XOR mode, for my personal use… if I turn the transparency down enough to see other layers you loose all contrast it makes it very hard on my eyes!
Tom, the point I tried to make in my bug report was that it could be semi-transparent. Ideally it would have opaque outline (is it the same as "stroke?) and nearly transparent fill. Personally I don’t think there’s even need for choosing the transparence level, just hard code one which makes it possible to see the clearance while also easily see the objects (and other clearance lines) under it.
1 Like
I would still suggest to add it as a user setable colour to the items tab. At least in the long term (not sure if it is allowed to add stuff there for a bugfix release.)
There simply is no benefit to hardcode such things. (Having it user setable not only frees up developer resources otherwise wasted on discussing which colour to choose but also allows users with different levels of vision impairment to tailor the colour to their personal needs.)
2 Likes
GPUs have their strengths in vectorized floating point operations. Such operations can be parallelized for every pixel. I am not sure GPUs include bitwise integer operands. I further doubt that the libraries used support it. (Transparency is something that is included in opengl. XOR rendering is not part of opengl.)
Bitwise operations might require using libraries like cuda which are build to parallelize general computation instead of typical graphics use. (XOR will be supported there as it is a basic function for crypto.)
I do not agree here. With complex multi layer boards the old rendering becomes confusing fast. Its strengths where two layer boards with filled zones shown. (But yes as suggested in my bug report it might be beneficial to have a rendering mode that preserves colours when transparency is used on a dark background.)
2 Likes
I just had another idea in which you can solve your clearance problem without violating DRC.
In Pcbnew there are some “net tie” components, which are basically 2 pads connected with copper. The goal is to be able to connect nets with different labels together, or to split off thin sections of a fat net. For example you want wide tracks for high current, but also need a thin track for feedback to read the voltage on that track.
You can make a few net tie components with very narrow or no clearance, and insert them on the PCB as components. This will also always prevent the interactive router from wanting to move them, and the clearance stays the same as you designed it and put it on the PCB.
GPUs are much more general than they were 10 years ago, even Terascale from 11 years ago-ish could probably do this. Note GCN and Nvidia GPUs which have comparable features these days, can do vectorized integer instructions at the same rate as floating point by design for compute reasons. Recently as of the past few years they can also do some 4x rate INT8 and 16x rate INT4 for AI compute reasons.
Also it obviously worked in Legacy mode… on potato hardware so it can’t be as hard as you imply though I imagine there were some tricks to minimize rendering work done there.
Just for reference GLSL 1.30 (aka OpenGL 3.0 from 2008) and greater should support these data types explicitly and ^ as an operator is definitely somethign that should work there.
A valid reason to extend features… but not to sideline the vast majority of 2 or even 4 layer users. When viewing 2 copper layers XOR is clearly superior… and arguably superior for multilayer boards since any blending mode is going to suck with more layers and complexity anyway so you may as well support displaying at least 2 or 3 layers at once in a high contrast manner. For instance you probably will only ever be working on 2-3 layers at once on a multilayer board even GND plane + 2 signal layers for instance, perhaps a mode where GND planes and the last 2 active signal layers are shown would be useful. Making the UI smart enough to know what layers I want to be looking at rather than trying to display too much is probably a better way to go.
Having done a few simple multilayer boards… the current opengl rendering is nigh useless and almost never shows what I want to see without lots of clicking and manual intervention. It trips me up every time I attempt to route a signal to a different layer because setting transparency is a complete non starter due to extremely bad contrast… XORing the previous and current layer and perhaps a 3rd layer (based on where another trace of the netlist you are trying to get the trace to exists) would be much better IMO. Some sort of Hybrid method of rendering may also be quite good… for example alpha blending of ground planes and XORing of signals etc…
Only supporting alpha blending of layers without any automation to cull layers you don’t need to view is basically optimizing badly for the least common case…
2 Likes
This statement is a gross oversimplification.
The XOR in KiCad V4 was more usable then then the transaprency is now. That I can agree with.
However, with XOR you’re simply stuck, you either do it or you don’t (pun inended, could not resist), while with transparency and especially changing transparency in a smart way has a huge potential for much better visibility, and clarity. At the moment XOR has just been dropped, and the basic functionality to use transparency has also only just been implemented. Yesterday I shared some thoughts about ways transparency can be improved upon, and I’m convined it has the potential to become much better than simple XOR can ever be.
2 Likes
The advantage to XOR for me is that the blended colors actually make sense… overlapping colors with only alpha transparency is inscrutable especially as you add more layers… you just end up turning off as many layers as possible anyway.
I think transparency only is a dead end… while yes it can technically display more layers at once, it can’t do so in a useful manner. At the very least the algorithem for blending the layers must be improved simple alpha blending doesn’t cut it.
1 Like
I’ve signed up to work on improving color settings for V6. Opacity and blending modes is one of the things on my list to look at. To be clear, we are not considering returning to “XOR” style drawing, but there are other ways to improve the “legibility” of the display of complex boards.
6 Likes
Hi Jon,
wold it be thinkable to try to implement color schemes for KiCAD? (as Eclipse, Visual Studio, QtCreator do) There are some beautiful color schemes around (Dracula, Solarized, etc.) and people with the ability and inclination to devote their time fine tuning them that could share them.
I liked the color scheme used by @Rene_Poschl, however it took me a while to try to replicate it, were dropping an XML file somewhere could have make it a breeze.
Anyway, looking forward to your work and ideas
Yes, I also like color schemes
You could have asked. I would have uploaded the relevant sections of the setup files to github.
Well they are now found under: https://github.com/poeschlr/kicad-helpers
4 Likes