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.
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...
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.
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.
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.
OpenGL drivers are often optimized for gaming and don't work so well when you step outside of the narrow feature set they use.
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.
the next stable release (2016)Shit
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)Shitbetter late than never
the next stable release (2016)
Shit
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?
Autorouting seems to not be a topic of interest by current KiCad developers.
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?
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.
So this can be fixed by profiling drivers and more tests on graphics cards, right? Can that be automated?
Can't that be mitigated by providing more developer documentation, modularization, abstraction and effective use of OOP?
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.
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.
** I thought CERN is sponsoring KiCad? What does that mean? They're giving money to hire more developers? or just contributing code?
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?
They are not optimized for gaming for the simple reason there are virtually no games using OpenGL.
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.
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!
You know, even LibreOffice uses OpenCL!