Mail Archives: geda-user/2017/01/18/05:02:33
--001a114f42fcbd92d705465b7df9
Content-Type: text/plain; charset=UTF-8
Hi Igor,
Sorry for top posting (on my phone).
The NoHoles (cached clipped polygon for rendering) could theoretically be
null, with the valid flag set.
"Clipped" could (should?) also be null, and if they are not NULL together,
that probably suggests a bug in the no holes dicing routine, or (perhaps
more likely) that the polygon data is invalid somehow.
Null clipped polygons might occur if say, the polygon is small, and gets
totally clipped away by other objects. Doesn't seem to apply in this case.
I'm not sure from memory if we even call into the renderer if clipped ==
NULL.
I'll take a poke what happens on my experimental GL branches, as they don't
use the NoHoles cache for rendering. Might give an extra data point.
Will let you know if I find anything.
Peter
On 18 Jan 2017 06:44, <gedau AT igor2 DOT repo DOT hu> wrote:
Hi all,
John Griessen reported a few bugs for pcb-rnd recently, from which one
seems to affect all versions of mainline from 4.0.0 back to 2011 (the fork)
and maybe even earlier.
Reproduction:
1. start the program without a file name, let it create an empty design
2. switch to the silk layer
3. draw a rectangle
4. go back to arrow mode (F11)
5. drag & drop the rectanlge to move it a bit
Expected result: rectangle moved, just like on any copper layer
What we get instead: rectangle disappears.
Below I'm sharing the result of my debugging so far in hope that mainline
developers will share a patch with me if they decide to fix this sooner
than I do.
The move code calls InitClip on the poly after moving the coords, and the
new state of the poly becomes seemingly inconsistent: .NoHoles is left
NULL, while .NoHolesValid is 1. Later on in the draw code, we look at
.NoHolesValid and decide we don't need to recalculate .NoHoles, which means
we think what we need to draw is empty.
I don't yet fully understand .NoHolesValid; is the above combination valid?
e.g. "valid=1 NoHoles=NULL" means "we have a valid empty poly". Or is it
invalid, e.g. valid should be 1 only if we have an up to date, non-empty
NoHoles? It's the InitClip() code that first resets .NoHoles and then can
return in two different ways without setting valid to 0.
TIA,
Igor2
--001a114f42fcbd92d705465b7df9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">Hi Igor,<div dir=3D"auto"><br></div><div dir=3D"auto">Sor=
ry for top posting (on my phone).</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">The NoHoles (cached clipped polygon for rendering) could theoreti=
cally be null, with the valid flag set.</div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">"Clipped" could (should?) also be null, and if th=
ey are not NULL together, that probably suggests a bug in the no holes dici=
ng routine, or (perhaps more likely) that the polygon data is invalid someh=
ow.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Null clipped polygon=
s might occur if say, the polygon is small, and gets totally clipped away b=
y other objects. Doesn't seem to apply in this case.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">I'm not sure from memory if we even ca=
ll into the renderer if clipped =3D=3D NULL.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">I'll take a poke what happens on my experimental G=
L branches, as they don't use the NoHoles cache for rendering. Might gi=
ve an extra data point.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Will let you know if I find anything.</div><div dir=3D"auto"><br></div><div=
dir=3D"auto">Peter</div><br><div class=3D"gmail_extra" dir=3D"auto"><br><d=
iv class=3D"gmail_quote">On 18 Jan 2017 06:44, <<a href=3D"mailto:gedau=
@igor2.repo.hu">gedau AT igor2 DOT repo DOT hu</a>> wrote:<br type=3D"attribution">=
<blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">Hi all,<br>
<br>
John Griessen reported a few bugs for pcb-rnd recently, from which one seem=
s to affect all versions of mainline from 4.0.0 back to 2011 (the fork) and=
maybe even earlier.<br>
<br>
Reproduction:<br>
<br>
1. start the program without a file name, let it create an empty design<br>
<br>
2. switch to the silk layer<br>
<br>
3. draw a rectangle<br>
<br>
4. go back to arrow mode (F11)<br>
<br>
5. drag & drop the rectanlge to move it a bit<br>
<br>
Expected result: rectangle moved, just like on any copper layer<br>
<br>
What we get instead: rectangle disappears.<br>
<br>
<br>
Below I'm sharing the result of my debugging so far in hope that mainli=
ne developers will share a patch with me if they decide to fix this sooner =
than I do.<br>
<br>
<br>
The move code calls InitClip on the poly after moving the coords, and the n=
ew state of the poly becomes seemingly inconsistent: .NoHoles is left NULL,=
while .NoHolesValid is 1. Later on in the draw code, we look at .NoHolesVa=
lid and decide we don't need to recalculate .NoHoles, which means we th=
ink what we need to draw is empty.<br>
<br>
I don't yet fully understand .NoHolesValid; is the above combination va=
lid? e.g. "valid=3D1 NoHoles=3DNULL" means "we have a valid =
empty poly". Or is it invalid, e.g. valid should be 1 only if we have =
an up to date, non-empty NoHoles? It's the InitClip() code that first r=
esets .NoHoles and then can return in two different ways without setting va=
lid to 0.<br>
<br>
TIA,<br>
<br>
Igor2<br>
</blockquote></div><br></div></div>
--001a114f42fcbd92d705465b7df9--
- Raw text -