Bug#906060: Coordinate overflow when rendering
Control: reassign -1 libcairo2 On Wed, Oct 23, 2019 at 02:07:43PM +0200, Simon Richter wrote: > On Wed, Oct 23, 2019 at 09:45:11AM +1300, Olly Betts wrote: > > > > This is a major showstopper for linking KiCad 5 against GTK3, so this > > > requires us to keep GTK2 around longer. > > > 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)? > > 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. Indeed not. > > 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: > > > > 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. > > 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. 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
Bug#906060: Coordinate overflow when rendering
Hi, On Wed, Oct 23, 2019 at 09:45:11AM +1300, Olly Betts wrote: > > This is a major showstopper for linking KiCad 5 against GTK3, so this > > requires us to keep GTK2 around longer. > 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)? 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. > If so, I think we can at least unassign this from wx and kicad. 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. > 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: > > 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. 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
Bug#906060: Coordinate overflow when rendering
Control: tags -1 +moreinfo On Mon, Aug 13, 2018 at 09:28:53PM +0200, Simon Richter wrote: > This is a major showstopper for linking KiCad 5 against GTK3, so this > requires us to keep GTK2 around longer. 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: > 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. Cheers, Olly
Bug#906060: Coordinate overflow when rendering
On 2018-08-13, Simon Richter wrote: > 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. 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.
Bug#906060: Coordinate overflow when rendering
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:30. 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)
