In this thread:
qu1ck wrote:
It’s dropped on linux distributions where gtk3 is the only option. Legacy toolkit is only supported on gtk2.
I would imagine those designers would be using the latest video cards to get fast rendering and operation.
It would interesting to see the fantastic features a “latest hardware” edition of kicad would have.
paulvdh,
Thanks for the link. I wasn’t sure why the legacy option disappeared.
For around EUR700 I can buy components for a PC with a Passmark rating of around 19000, more then 12x faster then my current PC.
- EUR180 Ryzen 3600
- EUR150 RX570 or XR580 Video.
- EUR150 16GB Ram.
- EUR110 Mobo.
- Miscellaneous components, SSD, Power supply and other stuff.
The fastest “regular” PC’s have a passmark rating of around 62000, more then 3 times faster than the top of what I would consider purchasing.
Oops. The top just jumped up to 81000…
Also, modern graphics cards can cost upto several thousand EUR, and you can put 4 of them in a PC.
I would not be surprised if a completely maxed out PC costs EUR30000 or more. It’s completely mad.
I’m no expert, but what about this:
“Support for the logical pixel operations in RGBA mode was introduced in OpenGL 1.1.”
call glEnable(GL_COLOR_LOGIC_OP)
CALL glLogicOp(GL_XOR)
Mentioned here
Edit: In Cairo it is called “compositing operator” (“blending” is something else). The mode here is probably CAIRO_OPERATOR_XOR but there are other interesting ones confusingly referred to as “blend modes” such as SCREEN or MULTIPLY that might be useful depending on whether the background is dark or light.
HiGreg,
I’m not an expert either, but that does look promising.
Thanks for doing some research.
As far as I remember from the glimpses of discussions, KiCad wouldn’t benefit much from newer graphics hw features. I vaguely remember a discussion about fixing or adding something small, very small thing, which wasn’t finally considered because of the OpenGL version limit. IMO the main points to consider are
- supporting existing hardware on which KiCad already is running for many people
- the feature benefits (which are small)
- the amount of work to be done to reach new nice features
- the amount of manpower to do that work
Taken these all together, it probably isn’t just worth of it to update the OpenGL requirement.
But if anyone really delves into the issues and comes up with working solutions (working code) to showcase the benefits of newer OpenGL, it might be considered.
Remember also that it’s already the case that KiCad has more than one graphics canvases using different technologies. Anyone could code a new one with different visual properties as long as the old ones define the functional features and the new one is optional. I can’t promise for the project, but if someone would really do all that work, it might be considered for inclusion. I don’t think the current developers are willing to do all that work, though.
BTW, if someone is inspired by this thread and starts coding, I have other wishes, too. I have thought that OpenGL possibilities are underutilized. The view is now completely static. I believe the user might benefit from some animated objects. I don’t mean moving things, but effects like flashing or pulsating (changing between normal and highlighted color over time).
Anyone with access to other graphically-advanced packages deal with the issue of multi-layer visibility?
It would be interesting to enable two more preference options:
OpenGL Routing Layer-Blend Mode
Cairo Routing Layer-Blend Mode
Both default to “normal” (current transparency setting) but then allow for the full selection of blend mode/composite operators, so people could experiment with what works best. Hopefully, the Cairo version and OpenGL version are both high enough to allow separate alpha calculation, which might also be supplied as an options as well. I suspect the number of options available, along with the color selection options, is too great for any single developer to test effectively enough to choose those parameters and bake them in. Might be interesting to allow these in a color palette setting as well. So I guess that’s five new options.
- OpenGL (“Advanced Canvas”) routing blend mode
- OpenGL routing alpha blend mode
- Cairo routing blend mode
- Cairo routing alpha blend mode
- Blend mode Override color palette setting
Where the selection algorithm is:
- If given in color palette AND override=false, use palette setting
- Else, use preference setting
This would allow a large number of settings to be tested by users and to determine if further options are warranted (e.g. if the standard display “non-routing” blend modes should be changed).
The limitation is always laptops, with some broken OpenGL driver on the built in graphics and no way to upgrade. Even new machines can have problems.
Still,
I am convinced a lot can be achieved by just handling the opacity in a smart way in combination with the order in which the layers are drawn. I am even convinced that with the right combination of this it would already be better than the old XOR.
One of my earlier posts about this:
(thought I made a more extensive post with better worked out ideas somewhere, but it seems lost in the bulk of history)
1 Like
Hi all,
I haven’t read this whole thread, but it’s true that KiCad 5 is not great at this compared to other tools. It’s something I’m putting significant development energy into improving for V6.
Going back to XOR I think is the wrong way to think about this – XOR is not very useful as a blending operation when you let people choose arbitrary colors, at least not if you want things to make sense.
I think a better way, based on my use of other tools and some experiments I’ve done in KiCad that are not yet ready to merge, is to do things that make it easier to manage what is visible, and to emphasize what is important. For example:
- Easy load and store of layer visibility states
- Opacity setting based on object type, not (just) on layer
- More flexible “high-contrast” mode including completely isolating a single layer quickly, applying an opacity multiplier to inactive layers, and things like that
- A better default color scheme with higher contrast
- Better net isolation / focus modes
- Better hole rendering
Stay tuned as I expect some of this to be in master sometime this summer.
2 Likes
Do you also have a solution that allows bright colours with opacity (ignoring background for opacity is a simplistic way i can come up but i have no clue if this would be possible)
Check out LayerViewSet plugin as one way to implement load/store of any desired combination of layers and types visibility (both tabs). It allows loading and storing on a stack, named settings (which also functions as “store”), and direct access to any named set or set on the stack, and independent load/store of layers, types, or both.
We could allow different blend modes to be used (although there are some differences between OpenGL and Cairo that mean that it will likely never be possible to get them to look identical)
Yes this is a good add-on, I recommend people use it.
Also, one reason I am not so focused on blending modes right now: I haven’t used another ECAD program that lets you configure them, and I have never wished for it. I suspect if some of the other features I mention get into KiCad, looking at better blending won’t be as called-for.
Altium uses a very similar blending operation to KiCad, for example, and I’ve never thought that the way opacity worked in that program made it hard to use or see things. It all comes down to being able to apply transparency to the right objects at the right time, in my opinion.
So, serious question, what are the right times? I.e what events with KiCad would cause a change in layers’ transparency? I can think of:
- Normal view
- Routing, where transparency might be different depending on which layer is being routed.
- Highlighting.
- Select? (Not sure about this one, the element highlighting seems sufficient)
Any others?
Sorry, I wasn’t super clear in my other post – I wasn’t talking about dynamic changes, just better flexibility. Per-type opacity and better high-contrast mode are 90% of what I want. I actually don’t want per-copper-layer opacity control, and think that it’s counterproductive once you have per-type opacity (I’ve been playing with this in a branch). But, opacity boosts in high-contrast mode could be interesting.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.