kicad-developers team mailing list archive

[Vesa Solonen <vesa.solonen@xxxxxxxx>]

Tomasz Wlostowski kirjoitti 22.10.2018 klo 17.29:

> Hi Vesa,
> 
> Thank you.

This is overly excessively polite :)
I consider my contribution very minor if not on the border of annoying
and was mostly expecting "Patches please!"...

> 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
> Orson:
> - 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).

This is what I would suggest for just Eeschema as transparency is not
that important there. Lots of sharp lines easy on the eyes are though.
Proper font rendering as well. Just to make staring at the diagrams as
comfortable as possible. Porting the PNS router to Eeshema as a stretch
goal...

> - 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.

For PCB side MSAA is fine as there is much more complex scene needs than
schematics. The artefacts will blend in pretty well.

The most of my concern was related to Eeschema and thats why it is
interesting to compare it with Cairo rendered Gschem. Gschem is very
good to use in that regard, but naturally gets slow when there is
enormous amount of detail in view. I have no idea will it be tolerable
at all on >2K5 resolutions.

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

That is a very good strategy, but loses the toolkit support for the view
e.g. abstracting the raw OpenGL code. My guess is that separating them
is the best for long term, but means more work anyway. Printing support
maybe...

> 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...

I have not checked, but just noticed that the code that uses QPainter
for plotting some interactive data is completely accelerated now. A
while ago X would burn half the core.

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

Agreed and understood. Open source is for the eternity not just next
quarter ;)

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

Indeed. I consider the current Qt licensing and support model very good
as it gives us best of the both, enough commercial momentum and free
software licenses. Even GnuRadio is about to drop wx as the prime time
for it seems to have gone. With Qt KiCad would run on Android as well,
not that I mind, but would anyway...

> Best,
> Tom

Thank you for the insightful and justifiable explanation. I know it
takes effort to, but I believe it is valued by others too.

-Vesa