Skip to content

fix: Using floating point math for arcs.#173

Merged
ooxi merged 1 commit intogerbv:mainfrom
eyal0:floating_point_arcs
May 25, 2023
Merged

fix: Using floating point math for arcs.#173
ooxi merged 1 commit intogerbv:mainfrom
eyal0:floating_point_arcs

Conversation

@eyal0
Copy link
Copy Markdown
Collaborator

@eyal0 eyal0 commented May 1, 2023

Arcs and lines don't always line up when the image is zoomed out because gdk expects integers so we do a lot of integer math. For example, under a lot of zoom out, we might be looking at arcs circles with a diameter of 5. When dividing by 2 to compute the radius, this causes a problem.

The solution is to do as much floating-point math as possible and only convert to integer at the very end, when we call the GDK functions to draw. In testing, this fixed #167.

Arcs and lines don't always line up when the image is zoomed out
because gdk expects integers so we do a lot of integer math.  For
example, under a lot of zoom out, we might be looking at arcs circles
with a diameter of 5.  When dividing by 2 to compute the radius, this
causes a problem.

The solution is to do as much floating-point math as possible and only
convert to integer at the very end, when we call the GDK functions to
draw.  In testing, this fixed gerbv#167.
@eyal0
Copy link
Copy Markdown
Collaborator Author

eyal0 commented May 1, 2023

To test, download the files from #167 and then compile and run gerbv like this:

make -j 20 && ./src/gerbv ~/Downloads/gerbers-Edge.Cuts.gbr

Go to rendering mode "Fast, with XOR". Then, click on the "-" in the menu bar 6 times.

Before:
image

After:
image

If I zoom out even further than I get some more artifacts but this is at least better than what we had before. The best solution would be to do all math in floating-point and only convert to integer when necessary.

@ooxi
Copy link
Copy Markdown
Contributor

ooxi commented May 25, 2023

Thank you! I'll finish the release of 2.9.7 and then merge this

@ooxi ooxi merged commit 9d53242 into gerbv:main May 25, 2023
rampageservices added a commit to SourceParts/gerbv that referenced this pull request Mar 10, 2026
Replace integer-truncating division (/ 2, >> 1) with round(... / 2.0)
when computing top-left coordinates for circles, macro primitives
(prim1, prim6, prim7), rectangles, and ovals in the GDK renderer.

Integer truncation causes off-by-one positioning of concentric
apertures (e.g. pad + hole) at low zoom levels, making them appear
misaligned. This extends the fix from PR gerbv#173 (which addressed arcs
only) to all remaining shape primitives.

Fixes gerbv#167
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Gerbv incorrectly rounds aperture coordinates in fast render mode

2 participants