default, opengl and cairo -- what are these?

[fivefish]

Other than changing the appearance of components on the screen, what is their purpose?

cairo seems to be buggy (I'm in OSX, don't know about windows).

When should I switch from one to the other? or is this just personal preferences? 

[rs20]

It is certainly a bit of an oddity -- but the way that keyboard shortcuts work differ slightly between "Default" and "OpenGL", and some of the newer features (e.g. routing around obstructions automatically) is only supported in OpenGL mode. I find myself switching between the two frequently, Default for normal manual routing, OpenGL for sneaking that trace through that little gap. I expect the differences will decrease over time.

[timofonic]

This is one of the things that confuse me in KiCad.


Hey KiCad developers:

 You are the coders if this great project and know your shit better than the rest, I appreciate a lot your efforts.

Maybe you already have a planning, but please clean this brainfuck mess. You would make lots if people happy, I'm very sure of it.

- The first time they mentioned me about GAL, I got really confused. And not only because it's the Spanish acronym of an illegal organization that existed in the past, but because I just wanted to use KiCad and their nice stuff without messing about weird configurations.
- I'm not a scientist, not a CS or EE graduate. I'm just a damn dumb electronics student at a damn vocational school that just happens to use Linux since lots of years ago, I have no clue about programming too.
* If hobbyists and dumb geeks aren't the target of KiCad but just the scientists and great minds, it's okay. I just want to be sure of it and continue suffering CadSoft Eagle to my disgrace.

I hope  just after the stable release:
-They very soon let only GAL in their codebase, removing all the rest modes/frameworks or how they call it. Make a branch out whatever is called, do massive removing and remove cruft.
* Or maybe developers have a lot more sophisticated ways to do this, but please don't waste time on non-GAL stuff.
- They clean and polish, improving GAL to be feature complete.
- They optimize and provide a fast software renderer for unlucky platforms or ancient computers.
- They clean again.
- Optimize...
...

What's the priority to resolve this situation by developers? What do you think about it? Are there more important stuff? I'm the first asking for lots of UX improvements, but I have the intuition GAL situation needs to be solved to make the rest better.

[Mechatrommer]

iirc, cairo seems to be another variant of 2d/3d render engine. in Windows XP it run slowly that i thought its software implemented. default is most likely, KiCAD own software renderer. OpenGL is everyone know... why they are there? you pick whats best for your hardware... and iirc, to activate interactive routing, you need to be in OpenGL mode...

[krivx]

It is certainly a bit of an oddity -- but the way that keyboard shortcuts work differ slightly between "Default" and "OpenGL", and some of the newer features (e.g. routing around obstructions automatically) is only supported in OpenGL mode. I find myself switching between the two frequently, Default for normal manual routing, OpenGL for sneaking that trace through that little gap. I expect the differences will decrease over time.

I think shortcuts have been unified in the latest versions.

[timofonic]

iirc, cairo seems to be another variant of 2d/3d render engine. in Windows XP it run slowly that i thought its software implemented. default is most likely, KiCAD own software renderer. OpenGL is everyone know... why they are there? you pick whats best for your hardware... and iirc, to activate interactive routing, you need to be in OpenGL mode...

So there's 3 rendering engines, okay.

The real problem is that their framework makes things a bit messy, certain features depend on each rendering engine.

Does this makes code duplication? Are there some kind of plan to solve it? I don't understand it, but I would love to.

[andersm]

OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use. It's pretty common to include a fallback backend, even the Cadence viewers I had to install at work come in default an no-OpenGL versions.

[rolycat]

Posted on the KiCad.Info forum by Tomasz Wlostowski, one of the CERN developers:

The OpenGL canvas is going to replace the old one as soon as all the features are ported - perhaps the next stable release (2016). The future of Cairo is uncertain, it's just too slow. Either someone optimizes it, writes another software renderer or it gets dropped.

[timofonic]

OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use. It's pretty common to include a fallback backend, even the Cadence viewers I had to install at work come in default an no-OpenGL versions.

But can't that be workarounded in some way? There's shaders, OpenCL and other stuff.


- Can GAL become a more developed abstraction layer in the future?
* What about using more APIs and becoming some kind of more general abstraction layer, even using platform dependent APIs.
* I'm not sure where WxWidgets fits here, maybe this could mean to reinvent the wheel in some way.
* That's just speculating, it would probably require a lot more developers.

I don't understand about the GAL design and many of other KiCad parts.

- Are there some document about it?

Posted on the KiCad.Info forum by Tomasz Wlostowski, one of the CERN developers:

The OpenGL canvas is going to replace the old one as soon as all the features are ported - perhaps the next stable release (2016). The future of Cairo is uncertain, it's just too slow. Either someone optimizes it, writes another software renderer or it gets dropped.

That's interesting to know. I wonder what's the priority of this against other items.

I'm worried about systems unable to provide OpenGL or the performance not being good enough. What are the requirements of GAL?

[krivx]

the next stable release (2016)

Shit 

[wraper]

OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use. It's pretty common to include a fallback backend, even the Cadence viewers I had to install at work come in default an no-OpenGL versions.

They are not optimized for gaming for the simple reason there are virtually no games using OpenGL. There is nothing to optimize for. The fact they are intentionally truncated on gaming cards so the pro cards with the same hardware could sell at ridiculous prices is another case.

[Mechatrommer]

OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use.

OpenGL is a mature library made by bunches of professors and experts in graphics industries, even mature than DirectX imho. i dont think its specific to Gaming. its a general 2D and 3D software to hardware pipelining engine for everything.

So there's 3 rendering engines, okay.
The real problem is that their framework makes things a bit messy, certain features depend on each rendering engine.
Does this makes code duplication? Are there some kind of plan to solve it? I don't understand it, but I would love to.

i suspect the newer features such as interactive routing are graphics intensive feature, from their hardware testing (i guess), software renderer just wont cut it and they assume users will curse if advanced features are enabled in software renderer. moreover this is a OSSW project developed in a span of long time by several independent developers, the newcoming developers just adding feature without knowing everything from the past. code duplication are ineffective way of making something, probably they just added conditional check and disable new features if advance rendering mode is not selected. to get the code everything effective, the new developer should master every single letter in the old code, so that takes time. as someone above said, the autorouting should be enabled now in normal mode, so i guess they got there to the core of the past code. cross your finger on this, they are working on it by the time i'm typing this. FWIW...

the next stable release (2016)

Shit 

better late than never

[timofonic]

OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use.

OpenGL is a mature library made by bunches of professors and experts in graphics industries, even mature than DirectX imho. i dont think its specific to Gaming. its a general 2D and 3D software to hardware pipelining engine for everything.

So this can be fixed by profiling drivers and more tests on graphics cards, right? Can that be automated?

So there's 3 rendering engines, okay.
The real problem is that their framework makes things a bit messy, certain features depend on each rendering engine.
Does this makes code duplication? Are there some kind of plan to solve it? I don't understand it, but I would love to.

i suspect the newer features such as interactive routing are graphics intensive feature, from their hardware testing (i guess), software renderer just wont cut it and they assume users will curse if advanced features are enabled in software renderer. moreover this is a OSSW project developed in a span of long time by several independent developers, the newcoming developers just adding feature without knowing everything from the past. code duplication are ineffective way of making something, probably they just added conditional check and disable new features if advance rendering mode is not selected. to get the code everything effective, the new developer should master every single letter in the old code, so that takes time.

Can't that be mitigated by providing more developer documentation, modularization, abstraction and effective use of OOP?

I'm not sure about how KiCad is coded, but they use C++ and Python.

I'm a layman at this, but I'm curious as I would like to learn programming someday.

as someone above said, the autorouting should be enabled now in normal mode, so i guess they got there to the core of the past code. cross your finger on this, they are working on it by the time i'm typing this. FWIW...

Autorouting seems to not be a topic of interest by current KiCad developers. They already integrated FreeRouting, but it's a dead project and the Java dependence isn't desirable too.

There's a promising project called C-PCB from a developer (there's a forum thread in this forum and the author replied too), it would be great if someone helps that developer. Maybe it can be interesting for other projects such as gEDA's PCB and even Eagle users if finally surpasses FreeRouting capabilities.

I'm currently a bit busy to get into the computer, but I plan to test C-PCB and do other pending stuff.

If you refer to PnS routing, that's a different thing. Maybe it have similarities with autorouting in terms of algorithms and such.

the next stable release (2016)

Shit 

better late than never

I would prefer a "release early, release often " approach, but maybe this requires a bigger team and a wider userbase providing more feedback such as bugs.

What do you all think about it?

I would like to know the opinions from KiCad developers too, not sure if they are watching us.

[Bassman59]

the next stable release (2016)

Shit 

You misread. There is a stable release which is imminent. It has been delayed because they're still squashing bugs. The next stable release will be next year.

[Bassman59]

OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use.

OpenGL is a mature library made by bunches of professors and experts in graphics industries, even mature than DirectX imho. i dont think its specific to Gaming. its a general 2D and 3D software to hardware pipelining engine for everything.

So this can be fixed by profiling drivers and more tests on graphics cards, right? Can that be automated?

Sure, the tests can be automated. Question: who supplies the vast array of graphics hardware on which to test?

[Bassman59]

Autorouting seems to not be a topic of interest by current KiCad developers.

It's also not a topic of interest among people who actually lay out circuit boards that are not trivial.

[timofonic]

OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use.

OpenGL is a mature library made by bunches of professors and experts in graphics industries, even mature than DirectX imho. i dont think its specific to Gaming. its a general 2D and 3D software to hardware pipelining engine for everything.

So this can be fixed by profiling drivers and more tests on graphics cards, right? Can that be automated?

Sure, the tests can be automated. Question: who supplies the vast array of graphics hardware on which to test?

There's a possibility:


https://openbenchmarking.org

Maybe he could agree on providing resources to KiCad, as he already does with other projects such as Linux kernel.

Autorouting seems to not be a topic of interest by current KiCad developers.

It's also not a topic of interest among people who actually lay out circuit boards that are not trivial.

I understand. Autorouting helps me to learn manual routing, then I redo it or parts of the result.

But most of my designs are trivial, I'm at an early phase at learning electronics.

[Mechatrommer]

So this can be fixed by profiling drivers and more tests on graphics cards, right? Can that be automated?

for what? by "mature" i didnt mean every boards and drivers are or should be compliant to opengl standard, or more efficient than one another. by mature i mean opengl provides every possible functions in 2d/3d rendering job that a man can imagine. all you have to do is buy a decent opengl compliant graphic board (i guess every board does now), install opengl driver and hope for the best. in wingows though it stopped supporting latest opengl (only up to opengl 2 or something sad) because wingows want to worship their DirectX. but then back to this FREE OSSW kicad, i dont think profiling every drivers combined with any possible machine setup on earth should be their scope of job. they can though if... you are willing to provide your resources in doing so.

Can't that be mitigated by providing more developer documentation, modularization, abstraction and effective use of OOP?

can! if you are willing to provide your resources in doing so. having close communication with them and all...

as someone above said, the autorouting should be enabled now in normal mode, so i guess they got there to the core of the past code. cross your finger on this, they are working on it by the time i'm typing this. FWIW...

Autorouting seems to not be a topic of interest by current KiCad developers. They already integrated FreeRouting, but it's a dead project and the Java dependence isn't desirable too.

that was a mistype. i mean interactive routing, PnS or whatnot, sorry

I would prefer a "release early, release often " approach, but maybe this requires a bigger team and a wider userbase providing more feedback such as bugs.
What do you all think about it?

i think you should provide your resources in doing so... you can add your name to the 3 headed team now...
http://www.ohwr.org/projects/cern-kicad/wiki
http://www.ohwr.org/projects/cern-kicad/wiki/StudentProjects

I would like to know the opinions from KiCad developers too, not sure if they are watching us.

i guess they are not unless someone knock their door interupting their busy coding job, and direct them to this thread. even that i think they will not be that interested when they arrived since not much helpful input here... ... and by "helpful input" i mean something that can speed up their ever unfinished business in this matter...

[fivefish]

I'm trying to learn/discover/live with the default/opengl canvas quirks.  Some commands are fast on opengl but slow in default, and some commands only work in default but not in opengl. 

Hopefully the developers can move/implement all features from default to opengl canvas asap. I like the opengl canvas better, except for those instances where a command doesn't completely work in it.

** I thought CERN is sponsoring KiCad? What does that mean? They're giving money to hire more developers? or just contributing code?

[con-f-use]

** I thought CERN is sponsoring KiCad? What does that mean? They're giving money to hire more developers? or just contributing code?

Both. They pay two CERN people to work on KiCad and nothing but KiCad. Prior to that, they have occasionally contributed code.

[Bassman59]

I'm trying to learn/discover/live with the default/opengl canvas quirks.  Some commands are fast on opengl but slow in default, and some commands only work in default but not in opengl. 

Hopefully the developers can move/implement all features from default to opengl canvas asap. I like the opengl canvas better, except for those instances where a command doesn't completely work in it.

** I thought CERN is sponsoring KiCad? What does that mean? They're giving money to hire more developers? or just contributing code?

So what happened was that two CERN guys work on Kicad full time, and they contributed the GAL which is what supports the push-and-shove router. That was a major piece of work.

All of the Kicad devs are well aware that there are usability issues between the default canvas and the GAL (OpenGL) canvas, and they are working to unify it.

[andersm]

They are not optimized for gaming for the simple reason there are virtually no games using OpenGL.

That is completely false.

OpenGL is a mature library made by bunches of professors and experts in graphics industries, even mature than DirectX imho. i dont think its specific to Gaming. its a general 2D and 3D software to hardware pipelining engine for everything.

You have to differentiate between the standard and the vendor implementations. OpenGL isn't specific to gaming (neither is Direct3D), but the graphics industry has been almost completely been driven by gaming for the last ten years or so, simply because that's where the money is. This blogpost is a couple of years old by now, but illustrates some of the problems graphics programmers have to deal with. Back when 3D accelerators in home computers were still gaining popularity I remember hearing how most retail cards of the time were useless for CAD using OpenGL, since basic features like line drawing (which games didn't use) was often implemented in software in the driver.

[Icchan]

Hmm... some misinformation or misunderstandings about OpenGL on this thread, but long story short:

OpenGL is an API that allows developers to access GPU in easy and efficient way by abstracting the exact hardware behind sets of features that the hardware supports or doesn't. This support depends upon the drivers and the hardware itself and can be queried by the programmer.
It wasn't designed for games, but as an industry standard, open specification for utilizing 3D hardware. And it still is used a lot in the industry. Unfortunately Windows dominated in games after ~DirectX 7 and DX became defacto API to teach for game developers for decades. This will propably change in the future though.

Longer story continues:

OpenGL will be more commonly used with games in the future since cross platform releases for games are more common place and DX is windows/microsoft only API. Makes it easier to port your game if you choose OpenGL for your game/application. Not to even talk about Valves push towards Linux with Steam and new low level API's like Mantle which is reborn as Vulcan (next verson of OpenGL) that is basically the same AMD API that PS4 is using.

So the future of OpenGL is quite good in gaming.

About compatibility, OpenGL is designed to fall back to software rendering mode if the hardware can't support features that program requests. This ensures backwards compatibility over vast range of hardware by sacrificing performance but letting the software run regardless.

This isn't without limitations though and requires some driver support from the operating system or included software rendering framework in the application itself (e.g mesa).

And when we think about how much computing power goes to calculating the Push & Shove routing and when adjusting the track can change tens or hundreds of other objects at the same time, speed of rendering and calculating these algorithms is everything. And you really can't get there if your rendering engine isn't fast enough and is gobbling up your valuable CPU cycles while updating the scene.

Transition to OpenGL is natural one and will give the opportunity to render very large and complex boards with high frame rate and still saving CPU resources for calculations that GPU can't perform.

Not to talk about the possibility of having native 3D boards in KiCad like in Altium. It makes possible to rotate the board in any way you want, to have multiple viewports of the board open at the same time, fast anti aliasing, different materials, fast alpha blending and opacity, you name it. Real time copper pours (rendering speed isn't an issue anymore) and much, much more.

And if we think about it, any parallel calculations that GPU can perform should be performed by the GPU since it's superior in parallel calculations. These days modern GPU can be programmed like any CPU and can perform general computation using APIs like OpenCL if needed, for circuit simulation or any other requirement.

And what is Auto Routing or Push & Shove than huge amount of parallel computation to resolve conflicts and to do path finding while updating the graphics as fast as possible?

[timofonic]

Hmm... some misinformation or misunderstandings about OpenGL on this thread, but long story short:

OpenGL is an API that allows developers to access GPU in easy and efficient way by abstracting the exact hardware behind sets of features that the hardware supports or doesn't. This support depends upon the drivers and the hardware itself and can be queried by the programmer.
It wasn't designed for games, but as an industry standard, open specification for utilizing 3D hardware. And it still is used a lot in the industry. Unfortunately Windows dominated in games after ~DirectX 7 and DX became defacto API to teach for game developers for decades. This will propably change in the future though.

Longer story continues:

OpenGL will be more commonly used with games in the future since cross platform releases for games are more common place and DX is windows/microsoft only API. Makes it easier to port your game if you choose OpenGL for your game/application. Not to even talk about Valves push towards Linux with Steam and new low level API's like Mantle which is reborn as Vulcan (next verson of OpenGL) that is basically the same AMD API that PS4 is using.

So the future of OpenGL is quite good in gaming.

About compatibility, OpenGL is designed to fall back to software rendering mode if the hardware can't support features that program requests. This ensures backwards compatibility over vast range of hardware by sacrificing performance but letting the software run regardless.

This isn't without limitations though and requires some driver support from the operating system or included software rendering framework in the application itself (e.g mesa).

And when we think about how much computing power goes to calculating the Push & Shove routing and when adjusting the track can change tens or hundreds of other objects at the same time, speed of rendering and calculating these algorithms is everything. And you really can't get there if your rendering engine isn't fast enough and is gobbling up your valuable CPU cycles while updating the scene.

Transition to OpenGL is natural one and will give the opportunity to render very large and complex boards with high frame rate and still saving CPU resources for calculations that GPU can't perform.

Not to talk about the possibility of having native 3D boards in KiCad like in Altium. It makes possible to rotate the board in any way you want, to have multiple viewports of the board open at the same time, fast anti aliasing, different materials, fast alpha blending and opacity, you name it. Real time copper pours (rendering speed isn't an issue anymore) and much, much more.

And if we think about it, any parallel calculations that GPU can perform should be performed by the GPU since it's superior in parallel calculations. These days modern GPU can be programmed like any CPU and can perform general computation using APIs like OpenCL if needed, for circuit simulation or any other requirement.

And what is Auto Routing or Push & Shove than huge amount of parallel computation to resolve conflicts and to do path finding while updating the graphics as fast as possible?

That's very interesting reply. Thanks a lot!

I have hope in better OpenGL and Vulkan.

You know, even LibreOffice uses OpenCL!

[janoc]

That's very interesting reply. Thanks a lot!

I have hope in better OpenGL and Vulkan.

You know, even LibreOffice uses OpenCL!

OpenGL and Vulkan support depend entirely on graphic card vendors. For example AMD/ATI OpenGL performance is poor in Windows and outright horrible in Linux (which is, incidentally, the main Kicad development platform).

Vulkan is not something that will bring much benefit to applications like Kicad - it is pretty much a vaporware at the moment that will not make it to market for years. And even then the market adoption is not obvious. A good OpenGL canvas renderer will go a long way already.

You know, even LibreOffice uses OpenCL!

And OpenCL has nothing to do with OpenGL. OpenCL is a parallel computing API, meant to run on GPUs but not only (CPU and hybrid implementations exist as well). OpenCL support could be perhaps useful for things like autorouting, but that is a niche thing. I think that LibreOffice uses OpenCL optionally to speed up some calculations in Calc, but that's all.

It doesn't have anything to do with graphics whatsoever. Basically OpenCL is a competitor to CUDA from Nvidia, with, unfortunately, abysmal adoption and driver support - CUDA has completely steamrolled it.