Bug#906060: Coordinate overflow when rendering

[Simon Richter]

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