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
