Package: kicad,libwxgtk3.0-gtk3-0v5,libcairo2,libpixman-1-0 Severity: important
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 -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/40 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
