X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=8+VvPxvi5jN4FvqsRuzIbWSqrgEgmF3f4vdtdDya8pw=; b=BO6Tn2NxXAEmsuqYssu68iFyag1NUgjPXWD2l0b0nKuFh/XrN3NPxeKDdPEn71TWoJ Y+4jIAxjmimcXTuaE56lvUyvDLslzuAGTPZuUjmpSDKbxM44ibJQSDuTqZuQkS8ECqAl S2aTp/Ff+us4FPsP6W+KQcp0xQQA99cZ5dJdFyIVO6PghEEYRf7li98ek5QptfiTU8Ky gFC/noJVLUW6iJGX8YOxkWAgncRbZyKv9S113/fdtKo2u8qnw2uDWSLQRtr2CSCkuKfb UdNcgIlyd3rC4PFh2WcTsu5hmsqkjQ1wWfJLzzOXj5tmwBqIh3qZfzLtAV5AfiRCyddX k24Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=8+VvPxvi5jN4FvqsRuzIbWSqrgEgmF3f4vdtdDya8pw=; b=i2l3oM1s4b2JjtU0uNqfhVutfodsT2pjB63OA7TPzY8w3K6FVEyBoLwLYjDeuqaFj3 xEdQROTksaoRKsI3ScPEf5q/k2LtAgdjYQR3zpb9/huCBp7d4+MKf3Ulqo7HOYsktH9K JqbvVrpWPw2czgIv/k1nE01GsePOEQC8cF3oi7WwfmmRLcYB6pttkRESDgbTBxPzYEZO 0+ei/YsxX1H5uaGs4Lyaz0jleihGYUX8xXTdCmjI22xCEZ/0l1w9n9SvdZ1ajuNkYSbG mlJL9JeeQ/qCjLoxvacDIdPGbJftVgZi+bShD7vLDa4MEY94BLneayFO5XXTOYd+ip9B ZkwQ== X-Gm-Message-State: AIkVDXJxKFGEzItFJXuvCkPgbxg7iJO7aaicjXuBLxYP5L9ktL5MhPX8Drh5CJs4CaazwrxEWszWTTYEFktP2A== X-Received: by 10.55.45.129 with SMTP id t123mr1911741qkh.311.1484733649091; Wed, 18 Jan 2017 02:00:49 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References:

From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" Date: Wed, 18 Jan 2017 10:00:48 +0000 Message-ID: Subject: Re: [geda-user] [pcb] bugreport for 4.0.0 To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=001a114f42fcbd92d705465b7df9 Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk --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, 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

Hi Igor,

Sor= ry for top posting (on my phone).

The NoHoles (cached clipped polygon for rendering) could theoreti= cally be null, with the valid flag set.

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

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.

I'm not sure from memory if we even ca= ll into the renderer if clipped =3D=3D NULL.

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.

= 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 seem= s 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 mainli= ne 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 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.

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.

TIA,

Igor2

--001a114f42fcbd92d705465b7df9--