← Back to team overview

kicad-developers team mailing list archive

Re: Eeschema GAL arc rendering


On 10/20/2018 10:26 AM, jp charras wrote:
Le 20/10/2018 à 16:07, Jeff Young a écrit :
@JP, I thought I fixed the border/background problem.  (It’s also
possible I just stopped working on it because I wasn’t getting anywhere.)

Hi Jeff,

It is fixed for a given graphic item but not for overlapping items.

But there is still the issue for overlapping items.
The Legacy canvas draws the background, and then (after all background
items are drawn) the outlines, on top of the background areas.

Therefore, in legacy canvas, outlines are never masked by overlapping

I'm not sure this is related but here is what arc rendering looks like after JP's fix. It's rather ugly.

Do you have a case that exhibits it that I can look in to?

On 20 Oct 2018, at 12:21, jp charras <jp.charras@xxxxxxxxxx
<mailto:jp.charras@xxxxxxxxxx>> wrote:

Le 19/10/2018 à 22:12, Wayne Stambaugh a écrit :
I don't know if anyone is aware but there is an issue with rendering
symbols with arcs in the new Eeschema gal code.  Apparently, the legacy
canvas could be tricked into drawing a minimal line width using a
negative width value.  This cause the the gal canvas to draw a rather
interesting blob (you can check this by opening any nor gate symbol in
the 4xxx library.  The solution proposed by the librarians is to us the
minimal 1mil line width but the rendered results are less than ideal in
the legacy canvas[1].  Anyone have any ideas about how to resolve this?
I would prefer that the gal canvases render symbols the same as the
legacy canvas without have two sets of symbol libraries.




This is an issue with polylines.

In 5.0 you cannot even select a item having a negative line width.

This is an issue with very large negative values ( a value = -1 does not
create this issue) for line width.

I just committed a workaround for this issue.

This is a workaround because you cannot (currently) edit items with a
negative line thickness.

A full fix is a bit more complex, because items with background fill
must be drawn on the background at least the filled area), and all other
items on top, after the background fill, in any case (for instance when
moving/placing an object in libedit).

I know Jeff has already worked on this problem, so because he has a
better knowledge of priority drawings, I'll leave it fix this issue (if
he agree, of course)

Jean-Pierre CHARRAS

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

Attachment: eeschema-gal-arc-rendering.png
Description: PNG image

Follow ups