Hello,
it might perhaps be worthwile to add Pixel-Snapping to the
vertex/geometry shader, depending on the introduced relative error. Of
course pixel snapping geometry is always altering reality in favor of
"clean" graphics, but if the error is reasonably small, it's mostly the
ERC that needs to do it correctly, right?
Michael
Am 22.10.2018 um 16:29 schrieb Tomasz Wlostowski:
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
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).
- 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!
Best,
Tom
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
