kicad-developers team mailing list archive
Mailing list archive
Re: Kicad's way of drawing filled zones
Wayne Stambaugh <stambaughw@xxxxxxxxx>
Mon, 13 May 2019 11:46:44 -0400
addr=stambaughw@xxxxxxxxx; prefer-encrypt=mutual; keydata= mQGiBEM0hxQRBAC2fNh3YOVLu1d5GZ0SbrTNldGiGnCJPLqzEnqFX9v6jmf33TMt6EmSLkl6 Wtfkoj0nVwKxcYmJkA8DX0QAokBkwNIzhSsBzQvthBLIk/5LnPVVKrEXOcL4mUyH1doKlkaE slgJozNa6Av+oavcvD02o1zJOloBbaHlNlyRt7fKswCgtIFlVjWggVH/15KfWk+Qo5JVPbME AIUBAQyL2OAx0n60AWec2WHnO9buHuG0ibtICgUMkE+2MRmYyKwYRdyVwGoIUemFuOyHp0AJ InX4T+vy2E7vkwODqjtMLfIoRkokW74Fi4nrvjlhOAw/vdq/twLbAmR9MOfPTpR4y7kQy1O2 /n+RkkRvh26vTzfbQmrH7cBJhk6aA/9Uwvu3E4zNJgHVZeS0HyWtmR1eOPPRbnkPgJTToX5O KMKzTJI/FX6kT7cFoCamitHrW3BJP4Dx+cMMsa47EGxqVTdbVJ4LjogsXTXxb+0Fn1u4zBdx x3Cer6O7+hqWy7zvpzeC6nSREjqDKa5CgHtv/GLm5uFPOmsjAsnHj2tlBrQmV2F5bmUgU3Rh bWJhdWdoIDxzdGFtYmF1Z2h3QGdtYWlsLmNvbT6IeAQTEQIAOBYhBOffs6CbblRzBkv33BtR cWlZ+CReBQJbFBS2AhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEBtRcWlZ+CReMI8A nRbrLkzp7+c2f0vX7sfg4ICX8LAKAJ9uClo4uJajmZa5zZrL2nKdZlUwIrkCDQRDNIcxEAgA gCru+3/aOC6RCjpvYC72wY+d5SmHphC6yeiV2/mOumyt5MLo/Ps2GznZr11JspqFk5K/Zpvp MMLqqjDZ39+50a2iKRQFJ6NlK+hJWMmj6eJygQrCwYo3Gjc6CqfrqUv+8VSnf/i5sIZmtOVA 4ZjML18MuBvMSsNdVLFJd5HNnYb1iOECpvqdPVh/21LLCEw7MUUGGnHBhCrmk2aJe5hFmcSN g4ldBcXrgMQBwf7aMVoobXBMFDb/IENByXn0llB7Gr2IFMRmNS9/p8s/II1Yl2bTqyX4FSz8 cfn7C9KEz7faZ7wzAcpwHFC/zs3JoAjJ0IEKdNUpIwAlKMzT3CzctwADBQf/cxpG28MKyrqk nNmq/8LQLy+x6FSYXBLjxQz9BiBNYeesDZQ6J5UbL1mjpJzMa5tLZypPYo4bbGyR22hrbyDF K7m6AcVaMIJKl98g4ukMutFfAJyRDaREH5Zl/X1P4u1Z/yaAIy9mKaNbaK1/5djNJ5wCTFen TUgAp9xdc30kGkFDdLJFp5uxDY4P0vaZiZdjUCvDM3Zjv5IzpNOfxVqTUBQNUP/BnnKhkk0p DTD6s3X8S+D0rOtEBQ8K0cwERI/E8EFa8nj0TNw4e2MYGR8wg+SxqJ7z5f0zPY0bO6G9DDFB wYCqzzPWGqdAh9vA5971TAbPERtdFybhkurozp2SfYhJBBgRAgAJBQJDNIcxAhsMAAoJEBtR cWlZ+CResHUAniULLCWiT26ieRTl7N2vS6vBo/DuAJ4m7Ss/gyiW6ybTn1ctDXAUgm2QVQ==
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
I guess I should weigh in on this issue. I would prefer we exhaust all
other options before bumping opengl to some later version. In the end,
we may have to abandoned older systems to get our performance to an
acceptable level with complex designs. I consider it more important to
serve our power users even if we have to ask users with older systems to
run an older version of KiCad for compatibility purposes. I hope we
don't have to do that but I am prepared to make that decision should it
On 5/13/19 5:54 AM, Tomasz Wlostowski wrote:
> I've been away for the weekend, here's the reply for all the
>> As far as I am aware, all commercial tools in the space have more
> advanced / modern system requirements than KiCad
>> The integrated Intel GPUs that are old enough to not have OpenGL 3.0
> are no longer supported by Intel
> Most (if not all) commercial EDA tools that use GPUs run under Windows
> only, which - paradoxically - gives the authors more freedom while
> choosing which GPU features to use. While OpenGL 2.1 (with only VS/PS
> shaders) is more-or-less supported on all Linux distros, GL 3.0 (with
> Geometry Shader support) is at least troublesome. I'm not sure if the
> speed/memory improvements provided by using GS will be more beneficial
> than additional support effort (fallback to 2.1 on unsupported systems?).
>> I have a *strong preference* for the solution 3.
> JP, You convinced me. This will solve the drawing issue without using
> heavy weapons (like GL 3.0). The only thing I'm not sure about is how to
> communicate the zone has a 0-width outline (still keeping the minimum
> width parameter in the file). Should we add zone property field in the
> file format?
> Removing "thick" polygon outlines solves some other issues too - I
> noticed Hyperlynx stores polygons with 0-width outlines, so the ones
> exported currently from KiCad are thinner than they should be because
> there's no inflation code in the exporter. Other EDA software exporters
> might also be affected.
>> I don't think any desktop computer released after 2010 would have
> issues with GL3 unless the hardware/OS is defective in some way.
> Hardware wouldn't, but drivers would. I still have issues running Half
> Life 2 EP2 (a 9-year old game) on a 4-year old laptop with Intel
> graphics under Linux...
>> Is it possible to determine openGL hardware support at runtime and use
> advanced API on newer machines while switching to fallback for older ones?
> I'd rather go to JP's idea of not using thick outlines instead of
> supporting rendering backends for two different OpenGL versions.
>> I don't see the need to tie OS support to hardware support. It's
> totally plausible to say, for example, "we'll support users on Debian 6
> but onlyif they have a <10 year old graphics card"
> Expect a lot of complaints on the bug tracker and the forums then :)
>> What about moving the knock-out code to the relative-error calculation
> first? Vias probably don't need 32 segments around the edge. Look at
> buildZoneFeatureHoleList(). We currently use 32 as the minimum value
> for segments per circle
> Good idea, especially combined with JP's solution. Are you going to fix
>> For instance: trying to render just the visible part of the board (
> culling ) or on the case on render the full board, implement some kind
> of "level of detail" to render a less accurate version ? ( eg as you
> pointed the vias could be a special case and simplified while on distance )
> We only render the visible part of the board only (glDrawElements() with
> indices generated from the currenlty visible item set obtained by
> traversing the VIEW's rtree). I'm not sure if it the geometry LOD
> wouldn't severely degrade the performance (the cost of generating and
> uploading a 1 GB VBO on LOD change - most of board geometry is cached in
> the GPU memory) or be just complex to implement (GAL has no LOD for
> primitives cached in the GPU RAM).
>> - render the via outline using a rectangular texture with transparent
>> - render the via hole in the zone as a simple square, side length =
> via diameter, and underneath the texture, so the texture's curve fills
> in the square's corners?
> Vias are already rendered using 1 triangle (not even quad) per each,
> except the 'texture' is generated by the pixel shader instead of being
>> Would be possible to share that Victor-s project or where we can get it?
> I have been asked to not share the board. Please ask Victor if he'd want
> to send you the design. Might be useful for optimizing 3D support.
> 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