kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

> Do you intend to support an new backend on  MacOS and Windows only, and
keep the current OpenGL backend on Linux (can't see a good reason for this)
?

No, if we switched to some abstraction layer such as bgfx, we'd use that on
all platforms.  That layer may then end up using OpenGL as _its_ backend.

> can say that any speed bottleneck is likely NOT in the rendering engine,
but in the rest of the code.

There are certain situations (that don't impact the majority of current
KiCad users) where the rendering engine is indeed a bottleneck in the PCB
editor and Gerber viewer.  As we try to make KiCad applicable to more
high-end designers, it could become an issue for more people.

-Jon

On Tue, Jan 11, 2022 at 4:46 PM pmx <pmx00003@xxxxxxx> wrote:

>
>
> Le 11/01/2022 à 21:59, Jon Evans a écrit :
>
> The current offerings (e.g. bgfx) are generally multi-platform but without
> the software fallback option.
>
>
> OK, got it.
>
> I just had a look at bgfx, seems neat.
>
> BTW, the bgfx::Init() fuction seems to accept a
> BGFX_PCI_ID_SOFTWARE_RASTERIZER parameter, may be the trick (or not...)
>
> Now, I totally agree that there is no point to develop/support a private,
> updated, fallback rendering engine from scratch in the future.
>
>
>
> Yes, OpenGL will likely remain supported on systems other than Windows/Mac
> for now at least, but we at some point will have to decide if we want to
> bump our minimum OpenGL version to something higher than 2.1.
>
>
> Do you intend to support an new backend on  MacOS and Windows only, and
> keep the current OpenGL backend on Linux (can't see a good reason for this)
> ?
> If it were me, I wouldn't touch the current rendering code (i.e. like
> switching to OpenGL 4.x), and devote all the future effort toward the
> integration of the new graphics backend on all platforms.
>
> From my previous tests (Kicad 5.99), I can say that any speed bottleneck
> is likely NOT in the rendering engine, but in the rest of the code.
> I can't count how many Boost:: containers are scanned, and even
> temporarily created and deleted, when you play with the graphics elements
> in the schematics !
> (The 3D viewer is a different matter).
>
> Pierre.
>
>
>
>
>
>