kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 24/10/2018 13:32, Jeff Young wrote:
> If the pixel snapping happens in the shader then ERC wouldn’t know about it.  We just have to make sure that the snap direction is uniform so we don’t end up with visual mismatches between wires & pins (for instance).

I'll have a look at it.

T.
> 
> Then again, while I know the internals of Kicad pretty well I know almost nothing about OpenGL, so take this with a grain of salt.
> 
> Cheers,
> Jeff.
> 
> 
>> On 24 Oct 2018, at 07:39, Michael Steinberg <michsteinb@xxxxxxxxx> wrote:
>>
>> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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
>