Re: [Kicad-developers] Kicad's way of drawing filled zones

[jp charras]

Le 19/05/2019 à 21:28, jp charras a écrit :
> Le 18/05/2019 à 14:13, Tomasz Wlostowski a écrit :
>> On 13/05/2019 12:58, jp charras wrote:
>>> If we are talking about V6.0 version, we should add zone property field
>>> in the file format like (outline_thickness 0.0) to avoid serious issues
>>> (generating broken boards for fabrication).
>>>
>>
>> Hi JP,
>>
>> Are you going to work on this (commit code)?
>>

Hi Tom,

Are you working on that?

If not, now Seth committed the last code about zones, I can finalize my
work on zone filled areas without thickness outlines.

(This is not a lot of changes)

Thanks.


-- 
Jean-Pierre CHARRAS

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Seth Hillbrand]

Am 2019-05-19 19:27, schrieb Seth Hillbrand:

Am 2019-05-19 15:28, schrieb jp charras:

It also could be worth to commit the work on Removing segment
hard-coding, because zone filled polygons optimization also include
circle to segments optimization.


I think the consensus was to make the acceptable error size
configurable and store it in the kicad_pcb file.  I am updating my
branch to do this and will e-mail the list for some testing before
pushing.  Hopefully this week.



Hi All-

I've pushed the latest code for customizing the approximation level to 
my branch [1].  Please have a go at testing it.  It includes the 
modification to the kicad_pcb file, removing the legacy 
segments_per_zone and adding a board-level max_error setting.


You can set this value in the Board Setup/Design Rules dialog.  I clamp 
it between 0.1 and 0.001mm.


If there are no objections to the approach this week, I'll push it to 
master this weekend.


-Seth


[1] https://code.launchpad.net/~sethh/kicad/+git/kicad/+ref/segments

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Seth Hillbrand]

Am 2019-05-19 15:28, schrieb jp charras:

It also could be worth to commit the work on Removing segment
hard-coding, because zone filled polygons optimization also include
circle to segments optimization.


I think the consensus was to make the acceptable error size configurable 
and store it in the kicad_pcb file.  I am updating my branch to do this 
and will e-mail the list for some testing before pushing.  Hopefully 
this week.


Best-
Seth

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[jp charras]

Le 18/05/2019 à 14:13, Tomasz Wlostowski a écrit :
> On 13/05/2019 12:58, jp charras wrote:
>> If we are talking about V6.0 version, we should add zone property field
>> in the file format like (outline_thickness 0.0) to avoid serious issues
>> (generating broken boards for fabrication).
>>
> 
> Hi JP,
> 
> Are you going to work on this (commit code)?
> 
>> Perhaps also adding a parameter like (circle_optimization [low, normal,
>> high] to optimize shapes with arc/circle items (perhaps useful in
>> microwave applications)
> 
> I'm OK with it. Seth?
> 
>>
>> I am not a specialist of Hyperlynx and other similar tools, but i am
>> guessing it is not the only one tool that does not handle thick outlines
>> in polygons.
> 
> IIRC Altium and Cadence store filled zones as borderless polygons.
> 
> Tom
> 
> 

I recently spent a bit of time on some annoying bugs, but I just
finished, so I can work on the outline thickness fix, if you are not
working on this fix.
No problem (I made some work to see what happens with border-less filled
polygons in zones).
Just tell me.

It also could be worth to commit the work on Removing segment
hard-coding, because zone filled polygons optimization also include
circle to segments optimization.

-- 
Jean-Pierre CHARRAS

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Seth Hillbrand]

Am 2019-05-18 08:13, schrieb Tomasz Wlostowski:

On 13/05/2019 12:58, jp charras wrote:

Perhaps also adding a parameter like (circle_optimization [low, 
normal,

high] to optimize shapes with arc/circle items (perhaps useful in
microwave applications)


I'm OK with it. Seth?


Yes.  Since the circle approximation affects the board contents, we 
store a parameter for that in the board file.  I am working on 
implementing it as a board-level setting for maximum absolute error.  
This will replace the zone-specific setting of segments per circle.


-Seth

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Tomasz Wlostowski]

On 13/05/2019 12:58, jp charras wrote:
> If we are talking about V6.0 version, we should add zone property field
> in the file format like (outline_thickness 0.0) to avoid serious issues
> (generating broken boards for fabrication).
> 

Hi JP,

Are you going to work on this (commit code)?

> Perhaps also adding a parameter like (circle_optimization [low, normal,
> high] to optimize shapes with arc/circle items (perhaps useful in
> microwave applications)

I'm OK with it. Seth?

> 
> I am not a specialist of Hyperlynx and other similar tools, but i am
> guessing it is not the only one tool that does not handle thick outlines
> in polygons.

IIRC Altium and Cadence store filled zones as borderless polygons.

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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Wayne Stambaugh]

Hey Tom,

On 5/14/19 4:34 AM, Tomasz Wlostowski wrote:
> On 13/05/2019 17:46, Wayne Stambaugh wrote:
>> I guess I should weigh in on this issue.  I would prefer we exhaust all
>> other options before bumping opengl to some later version.
> 
> Hi Wayne,
> 
> I think JP's solution is the way to go, it fixes the original issue
> instead of working it around. What's your opinion?

I'm fine with JP's solution.  I seem to remember some concern about
possibly breaking some of the exporting and/or plotting so we need to be
careful in that regard.

Cheers,

Wayne

> 
> Cheers,
> 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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Tomasz Wlostowski]

On 13/05/2019 17:46, Wayne Stambaugh wrote:
> I guess I should weigh in on this issue.  I would prefer we exhaust all
> other options before bumping opengl to some later version.

Hi Wayne,

I think JP's solution is the way to go, it fixes the original issue
instead of working it around. What's your opinion?

Cheers,
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Wayne Stambaugh]

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
be necessary.

Cheers,

Wayne

On 5/13/19 5:54 AM, Tomasz Wlostowski wrote:
> Hi,
> 
> I've been away for the weekend, here's the reply for all the
> questions/comments:
> 
>> 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
> this?
> 
>> 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
> corners
>> - 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
> static.
> 
>> 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.
> 
> Best,
> Tom
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : 

Re: [Kicad-developers] Kicad's way of drawing filled zones

[jp charras]

Le 13/05/2019 à 11:54, Tomasz Wlostowski a écrit :
> Hi,
> 
> I've been away for the weekend, here's the reply for all the
> questions/comments:
> 
>> 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
> this?
> 
>> 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
> corners
>> - 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
> static.
> 
>> 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.
> 
> Best,
> Tom

Hi Tom,

If we are talking about V6.0 version, we should add zone property field
in the file format like (outline_thickness 0.0) to avoid serious issues
(generating broken boards for fabrication).

Perhaps also adding a parameter like (circle_optimization [low, normal,
high] to optimize shapes with arc/circle items (perhaps useful in
microwave applications)

I am not a specialist of Hyperlynx and other similar tools, but i am
guessing it is not the only one tool that does not handle thick outlines
in polygons.

A few (or many?) new features will create new file format info, and
therefore will create incompatibility with 5.x versions.

I made a few very rough tests, and I am thinking we can use to create
zone holes:
32 segments by circle for round and oval pads
16 segments by circle for vias and 

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Tomasz Wlostowski]

Hi,

I've been away for the weekend, here's the reply for all the
questions/comments:

> 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
this?

> 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
corners
> - 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
static.

> 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.

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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Ruth Ivimey-Cook]

Hi

Forgive me if this is what the 'boolean sum' option is, and I'm not 
familiar with the GL Api itself, but:


Would a possibility be to focus purely on the Vias for the moment, given 
how many there are:


- render the via outline using a rectangular texture with transparent 
corners


- 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?


Regards

Ruth

On 11/05/2019 12:06, jp charras wrote:

Le 10/05/2019 à 18:33, Tomasz Wlostowski a écrit :

Hi,

I've been recently playing with Victor's huge 32-layer PCB design and
trying to improve the performance of pcbnew for larger designs. This
board causes even pretty decent PCs to crash/render glitches due to
pcbnew's enormous VBO (Vertex Buffer) memory consumption.

It turns out it's caused by the way KiCad renders filled zones:
- the inside of a zone is drawn/plotted as a filled polygon with 0-width
boundary. This one not a problem - we already triangulate the polygons
and I recently developed a patch for the OpenGL GAL that allows reusing
vertices of triangulated polys in the VBO/Index buffer to further reduce
memory footprint.
- the thick outline is drawn with rounded segments with the width =
minimum width of the polygon. Since we don't have arcs in polygons, each
of round features (e.g. vias) surrounded by a zone gets a ton of tiny
segments in the polygon outline. Each rounded segment in OpenGL is
composed of 2 triangles, hence 6 vertices (that can't be reused...). For
Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
polygons alone. Disabling the outline drawing makes the renderer work
smooth again.

I've been experimenting with some ways to fix this:
- generating the thick outline strokes using a Geometry Shader (which
means bumping up GL 3.0+), which means farewell to many Linux/older
integrated Graphics users.
- caching a triangulated polygon which is a boolean sum of the filled
inside and the thick stroked outline. This takes a lot of time (~2
minutes for Victor's design) to load and still takes quite a bit of VBO
memory. Another downside is that the polygons are not fully WYSIWYG
(outline segments have true rounded corners, while the corners of the
displayed shape would be approximated with line segments).
- change the way KiCad handles filled zones to calculate the (stroke +
inside) boolean sum during zone filling process. It means changes to the
plotting/GAL/3D code, but no changes to the file format. We'll also be
forced to inform the users that they have to refill the zones if they
read a file generated by an older KiCad version.


Which solution would you prefer?
Cheers,
Tom

Hi Tom,

I have a *strong preference* for the solution 3:
- It does not require a bumping to GL 3.0. I am not thrilled by this idea.
- It works also in Cairo engine.
- It fixes a issue in connection calculations: a connection (pad, via
track end) is found if the reference position is inside the zone.
Inside the zone is currently inside the main polygon, not really the
full area (polygon+thick outline), so a few connections are missed.
Why I have used polygons with thick outlines:
Because the polygon library used at this time did not a good job to
inflate polygons (read a really bad job).
But this is not the case now with Clipper, that is a really great
polygon library.

I made a very fast test, and just tried these 2 changes:
- do not draw thick outlines
- Use 16 segments by circle to create holes and polygon inflate: this is
enough for this purpose. I am not sure other ECADs are better.
- and inflate the filled polygons by zone min thickness/2
the result is very good:
- filled polygon shapes are very good.
- the number of segments to draw filled polygons does not significantly
change.

Of course, using segments to draw thick outlines give a better look for
acute angles, but do not mix cosmetic criteria and technical criteria.



___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Andrew Zonenberg]

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 only
if they have a <10 year old graphics card"

According to Wikipedia, OpenGL 3.x support is available for cards as old as:
* NVIDIA GeForce 8 series (12 years old)
* ATI Radeon HD 2000 series (11 years old)
* Intel Sandy Bridge integrated graphics (8 years old)

Does the project have any official hardware age/spec cutoff at this
point? I don't think the 11/12 year age cutoff for discrete graphics is
unreasonable.

The only users we'd impact by switching the OpenGL cutoff to 3.x are
users of 11+ year old discrete GPUs or 8+ year old integrated GPUs, who
either are on ancient laptops (so no GPU upgrade possible) or have a
desktop but can't spare the cash for a cheap GL 3.x capable card.
Considering that Newegg lists an ancient Radeon HD 3450 (which supports
OpenGL 3.3) for 11 USD, this doesn't seem like a major burden.

On 11/05/2019 23:58, Andrew Lutsenko wrote:
> 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 believe that solution would be best of both worlds.
> Otherwise the only reasonable cut-off date would be when officially
> supported OS versions will not support hardware with given OpenGL
> version. (For hypothetical example if kernel 7.0 will drop driver
> support for HD2000 and the likes there is no sense in clinging to old
> api but graphics drivers live very long time).
> 
> Regards,
> Andrew
> 
> On Sat, May 11, 2019 at 7:33 AM jp charras  > wrote:
> 
> Le 11/05/2019 à 16:18, Jon Evans a écrit :
> > Hi JP,
> >
> > Thanks for the input, it's a good point. It sounds like in this case
> > there may be a technical solution that works fine in GL2.1 so I
> agree it
> > makes sense to avoid raising requirements if at all possible. 
> >
> > Do you have any thoughts about how we should handle this in the
> future,
> > if for some reason there is a technical challenge that cannot be
> solved
> > as easily without moving to a higher OpenGL version? (or some other
> > similar hardware support issue) Should we always design for 2.1, or is
> > there some time in the future when it becomes appropriate to expect
> > users to have something newer? 
> >
> > Best, 
> > Jon
> 
> Of course, if OpenGL 2.1 cannot solve a technical challenge, we can move
> to 3.0.
> 
> Moreover, in the future, more PCs will support 3.0.
> 
> However, generally speaking, I prefer better algorithms to more powerful
> PCs.
> 
> >
> >
> > On Sat, May 11, 2019, 07:27 jp charras  
> > >> wrote:
> >
> >     Le 10/05/2019 à 18:43, Jon Evans a écrit :
> >     > Does anyone have a good sense of which hardware / software
> platforms
> >     > would be impacted by a switch to OpenGL 3.0 as baseline
> requirement?
> >     >
> >     > As far as I am aware, all commercial tools in the space have
> more
> >     > advanced / modern system requirements than KiCad, with the
> possible
> >     > exception of Eagle.  We have to consider whether supporting old 
> >     > graphics cards goes counter to the desire to have KiCad
> handle more
> >     > professional use cases (including large designs).
> >     >
> >     > The integrated Intel GPUs that are old enough to not have OpenGL
> >     3.0 are
> >     > no longer supported by Intel (everything since HD2000 series has
> >     it, as
> >     > far as I know)
> >     >
> >     > -Jon
> >
> >     Hi Jon,
> >
> >     To be honest, I do not share your opinion, and I am not especially
> >     thrilled by switching to OpenGL 3.0 as baseline requirement as
> long as
> >     we can avoid it.
> >
> >     OpenGL 2.1 is a reasonable requirement.
> >
> >     What is a professional use case?
> >     I know at least 2 opposite cases:
> >     - A advanced user who designs very complex boards: he needs a
> recent and
> >     fast computer with 2 (or enev 3) monitors.
> >     - Classroom "users"
> >     They are also professional users who do not design very
> complex boards.
> >     But force updating the computers just to use Kicad is a
> serious issue:
> >     As a old teacher I am knowing what I am saying:
> >     In the department I worked before being retired, we have
> roughly 200 PCs
> >     (most of them are dual boot: Linux and Windows).
> >     Not of all are used to run Kicad, but many of them.
> >     Saying: our new Kicad version needs a recent computer+OS so
> you have to
> >     change 50 or 100 of your computers in a bit hard 

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Andrew Lutsenko]

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 believe that solution would be best of both worlds.
Otherwise the only reasonable cut-off date would be when officially
supported OS versions will not support hardware with given OpenGL version.
(For hypothetical example if kernel 7.0 will drop driver support for HD2000
and the likes there is no sense in clinging to old api but graphics drivers
live very long time).

Regards,
Andrew

On Sat, May 11, 2019 at 7:33 AM jp charras  wrote:

> Le 11/05/2019 à 16:18, Jon Evans a écrit :
> > Hi JP,
> >
> > Thanks for the input, it's a good point. It sounds like in this case
> > there may be a technical solution that works fine in GL2.1 so I agree it
> > makes sense to avoid raising requirements if at all possible.
> >
> > Do you have any thoughts about how we should handle this in the future,
> > if for some reason there is a technical challenge that cannot be solved
> > as easily without moving to a higher OpenGL version? (or some other
> > similar hardware support issue) Should we always design for 2.1, or is
> > there some time in the future when it becomes appropriate to expect
> > users to have something newer?
> >
> > Best,
> > Jon
>
> Of course, if OpenGL 2.1 cannot solve a technical challenge, we can move
> to 3.0.
>
> Moreover, in the future, more PCs will support 3.0.
>
> However, generally speaking, I prefer better algorithms to more powerful
> PCs.
>
> >
> >
> > On Sat, May 11, 2019, 07:27 jp charras  > > wrote:
> >
> > Le 10/05/2019 à 18:43, Jon Evans a écrit :
> > > Does anyone have a good sense of which hardware / software
> platforms
> > > would be impacted by a switch to OpenGL 3.0 as baseline
> requirement?
> > >
> > > As far as I am aware, all commercial tools in the space have more
> > > advanced / modern system requirements than KiCad, with the possible
> > > exception of Eagle.  We have to consider whether supporting old
> > > graphics cards goes counter to the desire to have KiCad handle more
> > > professional use cases (including large designs).
> > >
> > > The integrated Intel GPUs that are old enough to not have OpenGL
> > 3.0 are
> > > no longer supported by Intel (everything since HD2000 series has
> > it, as
> > > far as I know)
> > >
> > > -Jon
> >
> > Hi Jon,
> >
> > To be honest, I do not share your opinion, and I am not especially
> > thrilled by switching to OpenGL 3.0 as baseline requirement as long
> as
> > we can avoid it.
> >
> > OpenGL 2.1 is a reasonable requirement.
> >
> > What is a professional use case?
> > I know at least 2 opposite cases:
> > - A advanced user who designs very complex boards: he needs a recent
> and
> > fast computer with 2 (or enev 3) monitors.
> > - Classroom "users"
> > They are also professional users who do not design very complex
> boards.
> > But force updating the computers just to use Kicad is a serious
> issue:
> > As a old teacher I am knowing what I am saying:
> > In the department I worked before being retired, we have roughly 200
> PCs
> > (most of them are dual boot: Linux and Windows).
> > Not of all are used to run Kicad, but many of them.
> > Saying: our new Kicad version needs a recent computer+OS so you have
> to
> > change 50 or 100 of your computers in a bit hard for these users.
> >
> > >
> > > On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
> > >> Hi,
> > >>
> > >> I've been recently playing with Victor's huge 32-layer PCB design
> and
> > >> trying to improve the performance of pcbnew for larger designs.
> This
> > >> board causes even pretty decent PCs to crash/render glitches due
> to
> > >> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
> > >>
> > >> It turns out it's caused by the way KiCad renders filled zones:
> > >> - the inside of a zone is drawn/plotted as a filled polygon with
> > 0-width
> > >> boundary. This one not a problem - we already triangulate the
> > polygons
> > >> and I recently developed a patch for the OpenGL GAL that allows
> > reusing
> > >> vertices of triangulated polys in the VBO/Index buffer to further
> > reduce
> > >> memory footprint.
> > >> - the thick outline is drawn with rounded segments with the width
> =
> > >> minimum width of the polygon. Since we don't have arcs in
> > polygons, each
> > >> of round features (e.g. vias) surrounded by a zone gets a ton of
> tiny
> > >> segments in the polygon outline. Each rounded segment in OpenGL is
> > >> composed of 2 triangles, hence 6 vertices (that can't be
> > reused...). For
> > >> Victor's board it means 1 GB (sic!) of the VBO goes for outlines
> > of the
> > >> polygons alone. Disabling the 

Re: [Kicad-developers] Kicad's way of drawing filled zones

[jp charras]

Le 11/05/2019 à 16:18, Jon Evans a écrit :
> Hi JP,
> 
> Thanks for the input, it's a good point. It sounds like in this case
> there may be a technical solution that works fine in GL2.1 so I agree it
> makes sense to avoid raising requirements if at all possible. 
> 
> Do you have any thoughts about how we should handle this in the future,
> if for some reason there is a technical challenge that cannot be solved
> as easily without moving to a higher OpenGL version? (or some other
> similar hardware support issue) Should we always design for 2.1, or is
> there some time in the future when it becomes appropriate to expect
> users to have something newer? 
> 
> Best, 
> Jon

Of course, if OpenGL 2.1 cannot solve a technical challenge, we can move
to 3.0.

Moreover, in the future, more PCs will support 3.0.

However, generally speaking, I prefer better algorithms to more powerful
PCs.

> 
> 
> On Sat, May 11, 2019, 07:27 jp charras  > wrote:
> 
> Le 10/05/2019 à 18:43, Jon Evans a écrit :
> > Does anyone have a good sense of which hardware / software platforms
> > would be impacted by a switch to OpenGL 3.0 as baseline requirement?
> >
> > As far as I am aware, all commercial tools in the space have more
> > advanced / modern system requirements than KiCad, with the possible
> > exception of Eagle.  We have to consider whether supporting old 
> > graphics cards goes counter to the desire to have KiCad handle more
> > professional use cases (including large designs).
> >
> > The integrated Intel GPUs that are old enough to not have OpenGL
> 3.0 are
> > no longer supported by Intel (everything since HD2000 series has
> it, as
> > far as I know)
> >
> > -Jon
> 
> Hi Jon,
> 
> To be honest, I do not share your opinion, and I am not especially
> thrilled by switching to OpenGL 3.0 as baseline requirement as long as
> we can avoid it.
> 
> OpenGL 2.1 is a reasonable requirement.
> 
> What is a professional use case?
> I know at least 2 opposite cases:
> - A advanced user who designs very complex boards: he needs a recent and
> fast computer with 2 (or enev 3) monitors.
> - Classroom "users"
> They are also professional users who do not design very complex boards.
> But force updating the computers just to use Kicad is a serious issue:
> As a old teacher I am knowing what I am saying:
> In the department I worked before being retired, we have roughly 200 PCs
> (most of them are dual boot: Linux and Windows).
> Not of all are used to run Kicad, but many of them.
> Saying: our new Kicad version needs a recent computer+OS so you have to
> change 50 or 100 of your computers in a bit hard for these users.
> 
> >
> > On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
> >> Hi,
> >>
> >> I've been recently playing with Victor's huge 32-layer PCB design and
> >> trying to improve the performance of pcbnew for larger designs. This
> >> board causes even pretty decent PCs to crash/render glitches due to
> >> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
> >>
> >> It turns out it's caused by the way KiCad renders filled zones:
> >> - the inside of a zone is drawn/plotted as a filled polygon with
> 0-width
> >> boundary. This one not a problem - we already triangulate the
> polygons
> >> and I recently developed a patch for the OpenGL GAL that allows
> reusing
> >> vertices of triangulated polys in the VBO/Index buffer to further
> reduce
> >> memory footprint.
> >> - the thick outline is drawn with rounded segments with the width =
> >> minimum width of the polygon. Since we don't have arcs in
> polygons, each
> >> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
> >> segments in the polygon outline. Each rounded segment in OpenGL is
> >> composed of 2 triangles, hence 6 vertices (that can't be
> reused...). For
> >> Victor's board it means 1 GB (sic!) of the VBO goes for outlines
> of the
> >> polygons alone. Disabling the outline drawing makes the renderer work
> >> smooth again.
> >>
> >> I've been experimenting with some ways to fix this:
> >> - generating the thick outline strokes using a Geometry Shader (which
> >> means bumping up GL 3.0+), which means farewell to many Linux/older
> >> integrated Graphics users.
> >> - caching a triangulated polygon which is a boolean sum of the filled
> >> inside and the thick stroked outline. This takes a lot of time (~2
> >> minutes for Victor's design) to load and still takes quite a bit
> of VBO
> >> memory. Another downside is that the polygons are not fully WYSIWYG
> >> (outline segments have true rounded corners, while the corners of the
> >> displayed shape would be approximated with line segments).
>

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Jon Evans]

Hi JP,

Thanks for the input, it's a good point. It sounds like in this case there
may be a technical solution that works fine in GL2.1 so I agree it makes
sense to avoid raising requirements if at all possible.

Do you have any thoughts about how we should handle this in the future, if
for some reason there is a technical challenge that cannot be solved as
easily without moving to a higher OpenGL version? (or some other similar
hardware support issue) Should we always design for 2.1, or is there some
time in the future when it becomes appropriate to expect users to have
something newer?

Best,
Jon


On Sat, May 11, 2019, 07:27 jp charras  wrote:

> Le 10/05/2019 à 18:43, Jon Evans a écrit :
> > Does anyone have a good sense of which hardware / software platforms
> > would be impacted by a switch to OpenGL 3.0 as baseline requirement?
> >
> > As far as I am aware, all commercial tools in the space have more
> > advanced / modern system requirements than KiCad, with the possible
> > exception of Eagle.  We have to consider whether supporting old
> > graphics cards goes counter to the desire to have KiCad handle more
> > professional use cases (including large designs).
> >
> > The integrated Intel GPUs that are old enough to not have OpenGL 3.0 are
> > no longer supported by Intel (everything since HD2000 series has it, as
> > far as I know)
> >
> > -Jon
>
> Hi Jon,
>
> To be honest, I do not share your opinion, and I am not especially
> thrilled by switching to OpenGL 3.0 as baseline requirement as long as
> we can avoid it.
>
> OpenGL 2.1 is a reasonable requirement.
>
> What is a professional use case?
> I know at least 2 opposite cases:
> - A advanced user who designs very complex boards: he needs a recent and
> fast computer with 2 (or enev 3) monitors.
> - Classroom "users"
> They are also professional users who do not design very complex boards.
> But force updating the computers just to use Kicad is a serious issue:
> As a old teacher I am knowing what I am saying:
> In the department I worked before being retired, we have roughly 200 PCs
> (most of them are dual boot: Linux and Windows).
> Not of all are used to run Kicad, but many of them.
> Saying: our new Kicad version needs a recent computer+OS so you have to
> change 50 or 100 of your computers in a bit hard for these users.
>
> >
> > On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
> >> Hi,
> >>
> >> I've been recently playing with Victor's huge 32-layer PCB design and
> >> trying to improve the performance of pcbnew for larger designs. This
> >> board causes even pretty decent PCs to crash/render glitches due to
> >> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
> >>
> >> It turns out it's caused by the way KiCad renders filled zones:
> >> - the inside of a zone is drawn/plotted as a filled polygon with 0-width
> >> boundary. This one not a problem - we already triangulate the polygons
> >> and I recently developed a patch for the OpenGL GAL that allows reusing
> >> vertices of triangulated polys in the VBO/Index buffer to further reduce
> >> memory footprint.
> >> - the thick outline is drawn with rounded segments with the width =
> >> minimum width of the polygon. Since we don't have arcs in polygons, each
> >> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
> >> segments in the polygon outline. Each rounded segment in OpenGL is
> >> composed of 2 triangles, hence 6 vertices (that can't be reused...). For
> >> Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
> >> polygons alone. Disabling the outline drawing makes the renderer work
> >> smooth again.
> >>
> >> I've been experimenting with some ways to fix this:
> >> - generating the thick outline strokes using a Geometry Shader (which
> >> means bumping up GL 3.0+), which means farewell to many Linux/older
> >> integrated Graphics users.
> >> - caching a triangulated polygon which is a boolean sum of the filled
> >> inside and the thick stroked outline. This takes a lot of time (~2
> >> minutes for Victor's design) to load and still takes quite a bit of VBO
> >> memory. Another downside is that the polygons are not fully WYSIWYG
> >> (outline segments have true rounded corners, while the corners of the
> >> displayed shape would be approximated with line segments).
> >> - change the way KiCad handles filled zones to calculate the (stroke +
> >> inside) boolean sum during zone filling process. It means changes to the
> >> plotting/GAL/3D code, but no changes to the file format. We'll also be
> >> forced to inform the users that they have to refill the zones if they
> >> read a file generated by an older KiCad version.
> >>
> >>
> >> Which solution would you prefer?
> >> Cheers,
> >> Tom
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> 

Re: [Kicad-developers] Kicad's way of drawing filled zones

[jp charras]

Le 10/05/2019 à 18:43, Jon Evans a écrit :
> Does anyone have a good sense of which hardware / software platforms
> would be impacted by a switch to OpenGL 3.0 as baseline requirement?
> 
> As far as I am aware, all commercial tools in the space have more
> advanced / modern system requirements than KiCad, with the possible
> exception of Eagle.  We have to consider whether supporting old 
> graphics cards goes counter to the desire to have KiCad handle more
> professional use cases (including large designs).
> 
> The integrated Intel GPUs that are old enough to not have OpenGL 3.0 are
> no longer supported by Intel (everything since HD2000 series has it, as
> far as I know)
> 
> -Jon

Hi Jon,

To be honest, I do not share your opinion, and I am not especially
thrilled by switching to OpenGL 3.0 as baseline requirement as long as
we can avoid it.

OpenGL 2.1 is a reasonable requirement.

What is a professional use case?
I know at least 2 opposite cases:
- A advanced user who designs very complex boards: he needs a recent and
fast computer with 2 (or enev 3) monitors.
- Classroom "users"
They are also professional users who do not design very complex boards.
But force updating the computers just to use Kicad is a serious issue:
As a old teacher I am knowing what I am saying:
In the department I worked before being retired, we have roughly 200 PCs
(most of them are dual boot: Linux and Windows).
Not of all are used to run Kicad, but many of them.
Saying: our new Kicad version needs a recent computer+OS so you have to
change 50 or 100 of your computers in a bit hard for these users.

> 
> On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
>> Hi,
>>
>> I've been recently playing with Victor's huge 32-layer PCB design and
>> trying to improve the performance of pcbnew for larger designs. This
>> board causes even pretty decent PCs to crash/render glitches due to
>> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
>>
>> It turns out it's caused by the way KiCad renders filled zones:
>> - the inside of a zone is drawn/plotted as a filled polygon with 0-width
>> boundary. This one not a problem - we already triangulate the polygons
>> and I recently developed a patch for the OpenGL GAL that allows reusing
>> vertices of triangulated polys in the VBO/Index buffer to further reduce
>> memory footprint.
>> - the thick outline is drawn with rounded segments with the width =
>> minimum width of the polygon. Since we don't have arcs in polygons, each
>> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
>> segments in the polygon outline. Each rounded segment in OpenGL is
>> composed of 2 triangles, hence 6 vertices (that can't be reused...). For
>> Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
>> polygons alone. Disabling the outline drawing makes the renderer work
>> smooth again.
>>
>> I've been experimenting with some ways to fix this:
>> - generating the thick outline strokes using a Geometry Shader (which
>> means bumping up GL 3.0+), which means farewell to many Linux/older
>> integrated Graphics users.
>> - caching a triangulated polygon which is a boolean sum of the filled
>> inside and the thick stroked outline. This takes a lot of time (~2
>> minutes for Victor's design) to load and still takes quite a bit of VBO
>> memory. Another downside is that the polygons are not fully WYSIWYG
>> (outline segments have true rounded corners, while the corners of the
>> displayed shape would be approximated with line segments).
>> - change the way KiCad handles filled zones to calculate the (stroke +
>> inside) boolean sum during zone filling process. It means changes to the
>> plotting/GAL/3D code, but no changes to the file format. We'll also be
>> forced to inform the users that they have to refill the zones if they
>> read a file generated by an older KiCad version.
>>
>>
>> Which solution would you prefer?
>> Cheers,
>> 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
> 


-- 
Jean-Pierre CHARRAS

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[jp charras]

Le 10/05/2019 à 18:33, Tomasz Wlostowski a écrit :
> Hi,
> 
> I've been recently playing with Victor's huge 32-layer PCB design and
> trying to improve the performance of pcbnew for larger designs. This
> board causes even pretty decent PCs to crash/render glitches due to
> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
> 
> It turns out it's caused by the way KiCad renders filled zones:
> - the inside of a zone is drawn/plotted as a filled polygon with 0-width
> boundary. This one not a problem - we already triangulate the polygons
> and I recently developed a patch for the OpenGL GAL that allows reusing
> vertices of triangulated polys in the VBO/Index buffer to further reduce
> memory footprint.
> - the thick outline is drawn with rounded segments with the width =
> minimum width of the polygon. Since we don't have arcs in polygons, each
> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
> segments in the polygon outline. Each rounded segment in OpenGL is
> composed of 2 triangles, hence 6 vertices (that can't be reused...). For
> Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
> polygons alone. Disabling the outline drawing makes the renderer work
> smooth again.
> 
> I've been experimenting with some ways to fix this:
> - generating the thick outline strokes using a Geometry Shader (which
> means bumping up GL 3.0+), which means farewell to many Linux/older
> integrated Graphics users.
> - caching a triangulated polygon which is a boolean sum of the filled
> inside and the thick stroked outline. This takes a lot of time (~2
> minutes for Victor's design) to load and still takes quite a bit of VBO
> memory. Another downside is that the polygons are not fully WYSIWYG
> (outline segments have true rounded corners, while the corners of the
> displayed shape would be approximated with line segments).
> - change the way KiCad handles filled zones to calculate the (stroke +
> inside) boolean sum during zone filling process. It means changes to the
> plotting/GAL/3D code, but no changes to the file format. We'll also be
> forced to inform the users that they have to refill the zones if they
> read a file generated by an older KiCad version.
> 
> 
> Which solution would you prefer?
> Cheers,
> Tom

Hi Tom,

I have a *strong preference* for the solution 3:
- It does not require a bumping to GL 3.0. I am not thrilled by this idea.
- It works also in Cairo engine.
- It fixes a issue in connection calculations: a connection (pad, via
track end) is found if the reference position is inside the zone.
Inside the zone is currently inside the main polygon, not really the
full area (polygon+thick outline), so a few connections are missed.
Why I have used polygons with thick outlines:
Because the polygon library used at this time did not a good job to
inflate polygons (read a really bad job).
But this is not the case now with Clipper, that is a really great
polygon library.

I made a very fast test, and just tried these 2 changes:
- do not draw thick outlines
- Use 16 segments by circle to create holes and polygon inflate: this is
enough for this purpose. I am not sure other ECADs are better.
- and inflate the filled polygons by zone min thickness/2
the result is very good:
- filled polygon shapes are very good.
- the number of segments to draw filled polygons does not significantly
change.

Of course, using segments to draw thick outlines give a better look for
acute angles, but do not mix cosmetic criteria and technical criteria.

-- 
Jean-Pierre CHARRAS

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Jeff Young]

The non-zero width edges might be creating even larger problems.  If we have a 
round edge and we generate 32 segments for it, and those segments are non-zero 
width, then don’t we generate another 32 lines at the end of each segment to 
make it round?  Or do we use some kind of shader there?

> On 10 May 2019, at 18:30, Mário Luzeiro  wrote:
> 
> Hi Tomasz,
> 
> This is an interesting challenge!
> 
> Did you consider other approaches apart from the ones you listed?
> 
> I have no full knowledge how GAL is rendering so maybe some of my suggestions 
> may not make sense.
> 
> I believe GAL is already doing some cache of the layers using textures.
> It may not be possible to get a full buffer resolution of the board ( eg 
> memory limitation? )
> but could be possible to implement some kind of techniques used on game 
> engines?
> 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 )
> 
> Out of curiosity, is 3D viewer able to render that board? :P
> Would be possible to share that Victor-s project or where we can get it?
> 
> Regards,
> Mario Luzeiro
> 
> 
> From: Kicad-developers 
>  on behalf of 
> Tomasz Wlostowski 
> Sent: 10 May 2019 17:33
> To: Kicad Developers
> Subject: [Kicad-developers] Kicad's way of drawing filled zones
> 
> Hi,
> 
> I've been recently playing with Victor's huge 32-layer PCB design and
> trying to improve the performance of pcbnew for larger designs. This
> board causes even pretty decent PCs to crash/render glitches due to
> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
> 
> It turns out it's caused by the way KiCad renders filled zones:
> - the inside of a zone is drawn/plotted as a filled polygon with 0-width
> boundary. This one not a problem - we already triangulate the polygons
> and I recently developed a patch for the OpenGL GAL that allows reusing
> vertices of triangulated polys in the VBO/Index buffer to further reduce
> memory footprint.
> - the thick outline is drawn with rounded segments with the width =
> minimum width of the polygon. Since we don't have arcs in polygons, each
> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
> segments in the polygon outline. Each rounded segment in OpenGL is
> composed of 2 triangles, hence 6 vertices (that can't be reused...). For
> Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
> polygons alone. Disabling the outline drawing makes the renderer work
> smooth again.
> 
> I've been experimenting with some ways to fix this:
> - generating the thick outline strokes using a Geometry Shader (which
> means bumping up GL 3.0+), which means farewell to many Linux/older
> integrated Graphics users.
> - caching a triangulated polygon which is a boolean sum of the filled
> inside and the thick stroked outline. This takes a lot of time (~2
> minutes for Victor's design) to load and still takes quite a bit of VBO
> memory. Another downside is that the polygons are not fully WYSIWYG
> (outline segments have true rounded corners, while the corners of the
> displayed shape would be approximated with line segments).
> - change the way KiCad handles filled zones to calculate the (stroke +
> inside) boolean sum during zone filling process. It means changes to the
> plotting/GAL/3D code, but no changes to the file format. We'll also be
> forced to inform the users that they have to refill the zones if they
> read a file generated by an older KiCad version.
> 
> 
> Which solution would you prefer?
> Cheers,
> 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


___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Mário Luzeiro]

Hi Tomasz,

This is an interesting challenge!

Did you consider other approaches apart from the ones you listed?

I have no full knowledge how GAL is rendering so maybe some of my suggestions 
may not make sense.

I believe GAL is already doing some cache of the layers using textures.
It may not be possible to get a full buffer resolution of the board ( eg memory 
limitation? )
but could be possible to implement some kind of techniques used on game engines?
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 )

Out of curiosity, is 3D viewer able to render that board? :P
Would be possible to share that Victor-s project or where we can get it?

Regards,
Mario Luzeiro


From: Kicad-developers 
 on behalf of 
Tomasz Wlostowski 
Sent: 10 May 2019 17:33
To: Kicad Developers
Subject: [Kicad-developers] Kicad's way of drawing filled zones

Hi,

I've been recently playing with Victor's huge 32-layer PCB design and
trying to improve the performance of pcbnew for larger designs. This
board causes even pretty decent PCs to crash/render glitches due to
pcbnew's enormous VBO (Vertex Buffer) memory consumption.

It turns out it's caused by the way KiCad renders filled zones:
- the inside of a zone is drawn/plotted as a filled polygon with 0-width
boundary. This one not a problem - we already triangulate the polygons
and I recently developed a patch for the OpenGL GAL that allows reusing
vertices of triangulated polys in the VBO/Index buffer to further reduce
memory footprint.
- the thick outline is drawn with rounded segments with the width =
minimum width of the polygon. Since we don't have arcs in polygons, each
of round features (e.g. vias) surrounded by a zone gets a ton of tiny
segments in the polygon outline. Each rounded segment in OpenGL is
composed of 2 triangles, hence 6 vertices (that can't be reused...). For
Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
polygons alone. Disabling the outline drawing makes the renderer work
smooth again.

I've been experimenting with some ways to fix this:
- generating the thick outline strokes using a Geometry Shader (which
means bumping up GL 3.0+), which means farewell to many Linux/older
integrated Graphics users.
- caching a triangulated polygon which is a boolean sum of the filled
inside and the thick stroked outline. This takes a lot of time (~2
minutes for Victor's design) to load and still takes quite a bit of VBO
memory. Another downside is that the polygons are not fully WYSIWYG
(outline segments have true rounded corners, while the corners of the
displayed shape would be approximated with line segments).
- change the way KiCad handles filled zones to calculate the (stroke +
inside) boolean sum during zone filling process. It means changes to the
plotting/GAL/3D code, but no changes to the file format. We'll also be
forced to inform the users that they have to refill the zones if they
read a file generated by an older KiCad version.


Which solution would you prefer?
Cheers,
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Seth Hillbrand]

Am 2019-05-10 12:33, schrieb Tomasz Wlostowski:

Hi,

I've been recently playing with Victor's huge 32-layer PCB design and
trying to improve the performance of pcbnew for larger designs. This
board causes even pretty decent PCs to crash/render glitches due to
pcbnew's enormous VBO (Vertex Buffer) memory consumption.

It turns out it's caused by the way KiCad renders filled zones:
- the inside of a zone is drawn/plotted as a filled polygon with 
0-width

boundary. This one not a problem - we already triangulate the polygons
and I recently developed a patch for the OpenGL GAL that allows reusing
vertices of triangulated polys in the VBO/Index buffer to further 
reduce

memory footprint.
- the thick outline is drawn with rounded segments with the width =
minimum width of the polygon. Since we don't have arcs in polygons, 
each

of round features (e.g. vias) surrounded by a zone gets a ton of tiny
segments in the polygon outline. Each rounded segment in OpenGL is
composed of 2 triangles, hence 6 vertices (that can't be reused...). 
For

Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
polygons alone. Disabling the outline drawing makes the renderer work
smooth again.



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, so each via with a cutout has 32 segments, each 
of which have 32*3 points for the rounded edges.  So that's 3k worth of 
points per via.  If we moved to the relative error for the vias, most 
would be at ~14 segments (for a 6-mil via with 6 mil clearance) or only 
588 points.


Most of the code for the relative calculation is in place already.  We 
need to finish updating routines line 
TransformShapeWithClearanceToPolygon() and Inflate() to remove their 
dependence on segment count.


This might avoid the need for massive overhaul of the graphics engine.

-Seth

___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[José Ignacio]

I don't think any desktop computer released after 2010 would have issues
with GL3 unless the hardware/OS is defective in some way.

On Fri, May 10, 2019 at 11:43 AM Jon Evans  wrote:

> Does anyone have a good sense of which hardware / software platforms would
> be impacted by a switch to OpenGL 3.0 as baseline requirement?
>
> As far as I am aware, all commercial tools in the space have more advanced
> / modern system requirements than KiCad, with the possible exception of
> Eagle.  We have to consider whether supporting old  graphics cards goes
> counter to the desire to have KiCad handle more professional use cases
> (including large designs).
>
> The integrated Intel GPUs that are old enough to not have OpenGL 3.0 are
> no longer supported by Intel (everything since HD2000 series has it, as far
> as I know)
>
> -Jon
>
> On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
>
> Hi,
>
> I've been recently playing with Victor's huge 32-layer PCB design and
> trying to improve the performance of pcbnew for larger designs. This
> board causes even pretty decent PCs to crash/render glitches due to
> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
>
> It turns out it's caused by the way KiCad renders filled zones:
> - the inside of a zone is drawn/plotted as a filled polygon with 0-width
> boundary. This one not a problem - we already triangulate the polygons
> and I recently developed a patch for the OpenGL GAL that allows reusing
> vertices of triangulated polys in the VBO/Index buffer to further reduce
> memory footprint.
> - the thick outline is drawn with rounded segments with the width =
> minimum width of the polygon. Since we don't have arcs in polygons, each
> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
> segments in the polygon outline. Each rounded segment in OpenGL is
> composed of 2 triangles, hence 6 vertices (that can't be reused...). For
> Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
> polygons alone. Disabling the outline drawing makes the renderer work
> smooth again.
>
> I've been experimenting with some ways to fix this:
> - generating the thick outline strokes using a Geometry Shader (which
> means bumping up GL 3.0+), which means farewell to many Linux/older
> integrated Graphics users.
> - caching a triangulated polygon which is a boolean sum of the filled
> inside and the thick stroked outline. This takes a lot of time (~2
> minutes for Victor's design) to load and still takes quite a bit of VBO
> memory. Another downside is that the polygons are not fully WYSIWYG
> (outline segments have true rounded corners, while the corners of the
> displayed shape would be approximated with line segments).
> - change the way KiCad handles filled zones to calculate the (stroke +
> inside) boolean sum during zone filling process. It means changes to the
> plotting/GAL/3D code, but no changes to the file format. We'll also be
> forced to inform the users that they have to refill the zones if they
> read a file generated by an older KiCad version.
>
>
> Which solution would you prefer?
> Cheers,
> 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
>
___
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

Re: [Kicad-developers] Kicad's way of drawing filled zones

[Jon Evans]

Does anyone have a good sense of which hardware / software platforms would be 
impacted by a switch to OpenGL 3.0 as baseline requirement?

As far as I am aware, all commercial tools in the space have more advanced / 
modern system requirements than KiCad, with the possible exception of Eagle. We 
have to consider whether supporting old graphics cards goes counter to the 
desire to have KiCad handle more professional use cases (including large 
designs).

The integrated Intel GPUs that are old enough to not have OpenGL 3.0 are no 
longer supported by Intel (everything since HD2000 series has it, as far as I 
know)

-Jon

On Fri, May 10, 2019, at 12:33 PM, Tomasz Wlostowski wrote:
> Hi,
> 
> I've been recently playing with Victor's huge 32-layer PCB design and
> trying to improve the performance of pcbnew for larger designs. This
> board causes even pretty decent PCs to crash/render glitches due to
> pcbnew's enormous VBO (Vertex Buffer) memory consumption.
> 
> It turns out it's caused by the way KiCad renders filled zones:
> - the inside of a zone is drawn/plotted as a filled polygon with 0-width
> boundary. This one not a problem - we already triangulate the polygons
> and I recently developed a patch for the OpenGL GAL that allows reusing
> vertices of triangulated polys in the VBO/Index buffer to further reduce
> memory footprint.
> - the thick outline is drawn with rounded segments with the width =
> minimum width of the polygon. Since we don't have arcs in polygons, each
> of round features (e.g. vias) surrounded by a zone gets a ton of tiny
> segments in the polygon outline. Each rounded segment in OpenGL is
> composed of 2 triangles, hence 6 vertices (that can't be reused...). For
> Victor's board it means 1 GB (sic!) of the VBO goes for outlines of the
> polygons alone. Disabling the outline drawing makes the renderer work
> smooth again.
> 
> I've been experimenting with some ways to fix this:
> - generating the thick outline strokes using a Geometry Shader (which
> means bumping up GL 3.0+), which means farewell to many Linux/older
> integrated Graphics users.
> - caching a triangulated polygon which is a boolean sum of the filled
> inside and the thick stroked outline. This takes a lot of time (~2
> minutes for Victor's design) to load and still takes quite a bit of VBO
> memory. Another downside is that the polygons are not fully WYSIWYG
> (outline segments have true rounded corners, while the corners of the
> displayed shape would be approximated with line segments).
> - change the way KiCad handles filled zones to calculate the (stroke +
> inside) boolean sum during zone filling process. It means changes to the
> plotting/GAL/3D code, but no changes to the file format. We'll also be
> forced to inform the users that they have to refill the zones if they
> read a file generated by an older KiCad version.
> 
> 
> Which solution would you prefer?
> Cheers,
> 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