kicad-developers team mailing list archive
Mailing list archive
Re: OpenGL rendering, etc
Vesa Solonen <vesa.solonen@xxxxxxxx>
Mon, 22 Oct 2018 21:39:37 +0300
addr=vesa.solonen@xxxxxxxx; prefer-encrypt=mutual; keydata= xsDiBEiy9EERBAD82hFx3nitjEVNCtkuedqJkwrBgNRsQIsR4zmT0Oy1okWnkzSRyEZHkesA HQy5d5z1OAGSn8BHEL2tJdQKbOCRhEL21yj35T81euDhD3q7pAxrJwwYz5wAyJpZ6ejMGG/g WOrsn5YpdkpR7RxdQ8GUAf7okUoQDemWNY9F8ftZ4wCg+cTF1WmXVPhzKBwy5GVMpTfQehcD /REoeVu4bwm2wTOQpkbnYdR7jJ8XyaAhZVpciWkrm0EH3ES7WhVDmaXzWb8gThzKjurnth6U s4nV7o9vG06sMDzf2siu/Ugbn/QZ1HW9lw2GeXBxwdSbctKiKOukTGNyb2xHN9upETAh9b6f vhNa0nlk+k4kuzvilMmuFSNFZ23HA/4r6kEfa16uK3oR5GQScvIojo95b3LgY2KsrFD6A0b0 61YLZusEB6gIiZ/DcJ+FQy8hQ6u04AmOOXwrneCfluzJFGhaHwOEJj9jwEQN2JMqgjHuMD+v 99Vph+Lzdm9UGOodPKGJ1JL3YyY9QYHj4IedTmDngJaI/2aRB/pgbB2NZc0qVmVzYSBTb2xv bmVuIDx2ZXNhLnNvbG9uZW5AcmZzaGFtYWFuaXQuZmk+wmIEExECACIFAlG02fQCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHdUiFKgf4oRxqQAoLbMaHJyWTf3A5H/esvkN9mK piBLAKCJG8iROdaY5CTOrWIb4L/mlxOV7c7BTQRIsvRGEAgA2v+TJXKtFv5TFtqy2egg0ARX X0i8+LtRtPtsXOCWUN51sSX8/1o23MPSzynMJNOsZ8yMEU7I9dDpEnZLAcaBGNrxj6V69uM1 m4aAyds6Qqwm+/nyBDz0zwQwayQjypqRahNTzH9cjIbXOJElh7otGvfI/8PBKCWzu6t/DjiM 2+azFTodADR8w/VXtSmoz5l+ouqJbHKE3xsNFFWnUbfit3EgGrpq16GYFNKm4+h8DIGyvz4Y ycB2DmuoAq+toOUeiIzH1GYe2pwjVzLVG+8x6kU/DRl7Qzst8P+eX4uMSfdepqUVIvYO00+v vYuL9Dkfqiz2lzhuTy+uUmlwvE8A6wADBQf9FD+wb0OWOlF7rG4f3DmdHmKQIXunFy64khfX h4NnCmJspOfCQ9I+cw3vTeX9UwOHtBKFgUkt10lXYSoaaf7cXG7pTUTUKuy8IZeVd1e91WYq edTGYo9pI99mPP8q5mQFN4sV/pyYycyx8DREm7VMuprjAsoeZ6db6ZW+oweI6GkztCtXdPl4 Ui84FSS/CbSrXIoG9WkXz5DyHrfcEJpbYPMkY+ISnENlt5od/UdD+QlnqP907EJQhnBnftSm yrGzPx3Mzno3kDGBwzbmy7HRBFs4dTfFbgZnp1JJNbfStDtNlbgO3mIeHDG4J6shTNe/Bg2m Eauj7I/dpMnflWmkKMJJBBgRAgAJBQJIsvRGAhsMAAoJEHdUiFKgf4oRLjcAn19oVj+nNWXC 9SRamlTcNfp99bByAKD1R/uGemuAaJz3A46tUaEbVQ7Fww==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
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
> - 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
> - 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
> 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
> 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...
Thank you for the insightful and justifiable explanation. I know it
takes effort to, but I believe it is valued by others too.