Layer mixing color schemes help tremendously when routing multi-layer boards

That may be true. I don’t know what it would require, though. There are also some limitations due to supporting old (2.0?) OpenGL.

bitwise operators were added to GLSL in OpenGL 3.0 (2009)

so I guess the question is why KiCAD is pinned to a version released in 2004…

You should file an issue and report your findings. I don’t know if there are any real OpenGL experts in the development group so that they would have thought about all possibilities, or if there are some other obstacles.

Because KiCad is dedicated to support old hardware. The year of the specification is of course earlier than the hardware which doesn’t yet support later spec.

(Man this conversation must be difficult to follow to those who don’t know the order of our messages…)

I really hope that’s not how the developers think. If someone really can’t bother to upgrade their GPU for a decade, there’s always software openGL.

Leaving aside the lack of features, the modern pipeline and programming style is almost unrecognizably changed from OGL2.0.

The old XOR made a lot of things visible on the PCB, but all those colors also had disadvantages and even though you could see a lot of things, figuring out what was what was not always easy.

There are 2 reasons why the XOR way feels better.

  1. You get used to what you see, it’s a psychological thing.
  2. The current way opacity is handled is very simplistic in it’s implementation.

Instead of holding on to the XOR, what other tools are there in OpenGL which can help in making boards better viewable? How do other PCB programs handle this?

To give some contrast. Here is a different approach:

I would have to agree that, while I do think supporting a wide range of hardware is good, and even necessary, there comes a time when it can probably be assumed (whatever negatives go along with that) that there will be a limit to how old things should be.

First, as a pcb designer, my systems go through an upgrade cycle depending on how much support and features are needed. For example, win7 is done, so hardware needs to meet specs for win 10, and even if the hardware was good on win 7, the new software versions require win10, and that typically means better hardware. Although Linux allows wider hardware, the current new releases do much better with newer hardware specs.

For a hobbyist, I don’t think kicad should require an i-7 to not bog down (and I have never had a problem on any hardware I have used kicad 4 on), but I would imagine most computers are pretty new.

That said, kicad does keep some older versions available - and should, if the goal is usability for lower hardware requirements.

I would rather hear “to use on a dual core p2 computer, download kicad 4” than to suffer development decisions because everyone has to fall to the lowest hardware possible.

If the graphics cards are the limiting factor, set a minimum requirement of some baseline graphics available - some intel hd chip that comes in a medium budget laptop?

And thinking of the requirement side of kicad, I’m wondering if the legacy mode being gone from Ubunty20.04 might have to do with Ubuntu dropping python2, and maybe legacy mode needs python2?

I am using KiCad on a 12 year old Dualcore (E6550) with a passmark rating of around 1500, and with Linux Mint 19.3 XFCE it still works well enough that I am in doubt when I would be going to buy a newer PC. I did upgrade my pc with about the cheapest video card I could find some years ago (Nvidia N210) which was a great improvement over the original, but abysmally slow for today’s standards.

For KiCad it’s still fine. FreeCAD has become very slow 1 or 2 years ago. FreeCAD takes over a minute just to start up, which is quite horrible.

On the other hand, I’ve heard Wayne Stambaugh talking of people requesting more copper layers because they are nearing the KiCad limit and boards with several thousands of components. For those board’s you will need fast hardware, and speed for KiCad is a mayor issue.

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.

  1. OpenGL (“Advanced Canvas”) routing blend mode
  2. OpenGL routing alpha blend mode
  3. Cairo routing blend mode
  4. Cairo routing alpha blend mode
  5. Blend mode Override color palette setting

Where the selection algorithm is:

  1. If given in color palette AND override=false, use palette setting
  2. 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.