← Back to team overview

kicad-developers team mailing list archive

Re: OpenGL rendering, etc


On 21/10/2018 14:35, Vesa Solonen wrote:
> Hi
> After testing the new OpenGL renderer on Eeschema I did some comparisons
> and tried to find ways for improvement. The speed improvement is
> enormous as expected. Thanks!

Hi Vesa,

Thank you.
> The attached screenshot compares Eeschema and Gschem rendering of
> similar features. It is clear that Gschem grid fits everything on pixel
> centres and pushes the rounding error to "white space". Everything but
> grid fit lines is anti-aliased and nothing is scaled after rasterisation.
> In general MSAA is not good for anti-aliasing of line drawing vector
> source data. With vectors the AA is part of the rasterisation, not
> something to do afterwards as the group of pixels that resulted from
> rasterisation have already lost the meaning what they were about to
> represent, so the quality is lost. Especially pixel grid fitting is lost
> on scaling that shows as fuzzy lines in the example.

In general, OpenGL (or any other 3D API) is not good for drawing complex
2D antialiased graphics *without* blending artifacts and with correct
layer ordering. When we designed GAL, we considered several options with
- per-primitive shader-based antialiasing (as you suggested in your
first link). This is OK if you have no transparent objects to draw
(otherwise, it's difficult to avoid blending artifacts on overlapping
transparent objects on the same layer).
- the solution above with per-layer pixel/stencil buffer to avoid
artifacts, which is expensive in terms of raster operations (lots of
overdraw to composite the layers on top of each other)
- Native HW accelerated 2D graphics API, dropped because of lack of
standardization and large effort to support different 2D libraries on
multiple platforms.
- Z buffering with MSAA/SSAA. Its advantages are correct blending and
speed (especially for MSAA), at the price of some artifacts produced by
the MSAA algorithm.

We chose the last option, as the speed is most important in a CAE
program view. For the time being you can either enable 4x supersampling
(if you have an $80+ graphics card I bet it'll work lightning fast) or
dig out the old antialiased Cairo GAL from the repo. We removed it from
pcbnew 2 years ago because it was unusably slow, but it provided
beautifully antialiased and correctly blended images.

> I also remember the ocassional talk about Qt and by the effort that goes
> to working around wx bugs and non-features something else could be done
> on Qt. 

I'd rather have the view, tools and core frameworks independent from any
UI toolkit.

> The OpenGL accelerated QPainter is pretty convincing these days.

Does it support layers and artifact-free transparency? Last time I
checked it didn't. Some proprietary EDA tools I know use QGraphicsView
and the graphics are neither very fast nor look good. But maybe things
have changed...

> Instead of deepfakes the wx to Qt porting AI would be more productive...

I think using QPainter/QGraphicsView mixed with Kicad tool/view code
base is as bad as doing this with any other UI library.

On the other hand, Qt for the UI part of Kicad looks *very* interesting!


Follow ups