kicad-developers team mailing list archive
Mailing list archive
Re: OpenGL rendering, etc
On 10/22/2018 10:29 AM, Tomasz Wlostowski wrote:
> On 21/10/2018 14:35, Vesa Solonen wrote:
>> 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!
After v6 is released, we may want to take a closer look at Qt if the
wxWidgets/wxPython situation doesn't significantly improve by then. I
have no idea if python support for Qt is any better than wx so this just
may be my frustration with the current situation. As for the UI stuff
alone, I really don't have a preferences other than not spending an
entire version development cycle just to change UI toolkits.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp