Hi,

this bug is difficult to pin down to a specific package.

KiCad uses the graphics context from wxWidgets for rendering in the
schematic editor (which somewhat works) and the PCB editor (which fails
utterly).

When wxWidgets is linked against GTK 3, it uses a Cairo context for
rendering, as is proper for GTK 3.

Cairo is given appropriate coordinates (as doubles) for a path, into a
zoomed(!) canvas. The logical coordinates used are dependent on the current
zoom level, and the scaling factor between device and logical coordinates
is somewhere between 1:50 and 1:300000.

Depending on zoom level, different failure modes can be observed, but there
is no zoom level at which the rendering is correct. At some levels,
something resembling the correct output can be seen, but as if the
coordinates were wrapped modulo a certain number.

Short video is at http://psi5.com/~geier/overflow.ogv

This can be reproduced best by compiling KiCad with libwxgtk3.0-gtk3-dev
installed, running "pcbnew" and switching to "legacy" canvas.

Quick debugging has shown that the coordinates given to Cairo still make
sense, even if the zoom level makes them numerically large. As I'd need
significant time to debug into optimized drawing routines, I'd like to pass
this on. I suspect that this is mostly an interaction between Cairo and
Pixman, with an overflow happening somewhere in a conversion from double to
an integer type.

This is a major showstopper for linking KiCad 5 against GTK3, so this
requires us to keep GTK2 around longer.

   Simon

There are a few upstream bug reports filed against cairo for similar issues,
such as https://bugs.freedesktop.org/show_bug.cgi?id=102966 and
https://bugs.freedesktop.org/show_bug.cgi?id=81657. The 'Poppler' library has
tended to work around these by modifying the transformation matrix to not be so
large.

Control: tags -1 +moreinfo

The debian kicad package has now using the GTK3 flavour of wxwidgets3.0
for many months, so has this bug been solved (at least as far as kicad
and wxwidgets3.0 are concerned)?

If so, I think we can at least unassign this from wx and kicad.

If not, I'm very unclear what (as a maintainer of wxwidgets3.0) I'm
expected to do given that the problem clearly seem to lie lower down the
stack:

Cheers,
    Olly

Hi,

No, we rewrote the entire rendering engine so we render through wxGLCanvas
now in most cases, with a fallback where we apply the zoom ourselves before
rendering through Cairo directly. Hardly an ideal outcome.

This can be marked as fixed in kicad >= 5.1 probably, but it's still a
problem for rendering to a zoomed wx canvas through a wxDC.

In any case it's an upstream problem, either in Cairo or wx, depending on
whether large zoom levels are supposed to work in Cairo.

   Simon

Control: reassign -1 libcairo2

Indeed not.

I fear that having this assigned to multiple different packages is a
recipe for everybody assuming it's somebody else's problem and nobody
ever doing anything further about it.

The Cairo documentation has no mention of limits on supported zoom
levels:

https://developer.gnome.org/cairo/stable/cairo-Transformations.html#cairo-scale

Therefore I'd say this is a bug in Cairo (either it should support
arbitrary zooming limited only by the ranges of the types, or it should
clearly document the limits on zooming that it supports), and I'm
reassigning to just Cairo on that basis.

(It also seems Cairo really should support this rather than forcing all
callers who want to zoom by arbitrary amounts to work around the
limitation, and if it's too hard to Cairo to do this, I struggle to see
why it's easier for callers to handle it.)

If it's actually a Cairo documentation bug, once that's addressed this
can be assigned back and I can try to convince wx upstream they need to
somehow work around it.

Cheers,
    Olly