pcbnew does not draw correctly the default canvas with wx3 with gtk3

[Luca Mini]

Default canvas is not properly drawn, only very confused lines, and at different zoom level I see different things.
The picture attached is an example of what I see.
In the other canvases the board is drawn properly.
If I attempt to draw something like tracks nothing is drawn.

Bug verified on two laptop with the following hw:

LAPTOP 1
core i7
NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
8GB ram
fedora 20 64bit
kicad version 4986 (but the issue is in all prevous versions)
wxwidgets 3.0.0
gcc ver. 4.8.3

LAPTOP 2
core i7
NVIDIA Corporation GK107M [GeForce GT650M] (rev ff)
8GB ram
fedora 19 64bit
kicad version 4986 (but the issue is in all prevous versions)
wxwidgets 3.0.0
gcc ver. 4.8.2

the problem makes the program unusable.

[Luca Mini (luca-mini-freelance)]

Tested with wxWidget 2.8 and the default canvas is drawn correclty, so the problem is in the usage of wxwidget 3.0.0.

[David Zanetti (dave2-wetstring)]

This seems to have come back between BZR 5098 (which renders okay) and 5106 (which doesn't)

[Senthil Seveelavanan (s-seveelavanan)]

I'm getting perhaps related problems with the default canvas. The modules don't show up, but if one tries to move a 'not properly rendered module' (by guessing its position), it then shows up. But the other canvas's render fine AFAIK (cairo & opengl). However, after restart it seems to be working now.

[gilbert (gilbert-erlangen)]

Have the same problem here with r5054 (current stable) if compiled against wxGTK v3.0.0. With wxGTK 2.8.12 all is ok...

[Nick Østergaard (nickoe)]

Gilbert, can you try wxwidgets 3.0.2?

[Nick Østergaard (nickoe)]

I have now tested this on a fedora 20, and I see the same as you. This even with wxwidgets 3.0.2.

@Luca, what was your operating system?

[Maximilian Rehkopf (otakon-c)]

I see the same thing. It works when compiled against 2.8.12 but not with 3.0.2.

[bdien (vl624)]

I tried to build "kicad stable 4029" with wxwidgets-2.8.14 but still no change.

[Wayne Stambaugh (stambaughw)]

Which window manager are you using? We have seen rendering issues with the latest Ubuntu Unity. When the users have switched to the stock Gnome desktop, the rendering issues disappeared. If you are not using the stock Gnome desktop, please try switching to it temporarily to see if that fixes the rendering issues. If the stable version with wxWidgets 2.8 doesn't render correctly, my guess is that something has changed graphics chain that is causing the problem.

[Joris Putcuyps (joris-putcuyps-7)]

I'm using the standard XFCE spin of Fedora.

Just installed Gnome and switched to it but the rendering is the same.

2014-12-29 17:22 GMT+01:00 Wayne Stambaugh <email address hidden>:

> Which window manager are you using? We have seen rendering issues with
> the latest Ubuntu Unity. When the users have switched to the stock
> Gnome desktop, the rendering issues disappeared. If you are not using
> the stock Gnome desktop, please try switching to it temporarily to see
> if that fixes the rendering issues. If the stable version with
> wxWidgets 2.8 doesn't render correctly, my guess is that something has
> changed graphics chain that is causing the problem.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1339539
>
> Title:
> pcbnew does not draw correctly the default canvas
>
> Status in KiCad EDA Software Suite:
> New
>
> Bug description:
> Default canvas is not properly drawn, only very confused lines, and at
> different zoom level I see different things.
> The picture attached is an example of what I see.
> In the other canvases the board is drawn properly.
> If I attempt to draw something like tracks nothing is drawn.
>
> Bug verified on two laptop with the following hw:
>
> LAPTOP 1
> core i7
> NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
> 8GB ram
> fedora 20 64bit
> kicad version 4986 (but the issue is in all prevous versions)
> wxwidgets 3.0.0
> gcc ver. 4.8.3
>
> LAPTOP 2
> core i7
> NVIDIA Corporation GK107M [GeForce GT650M] (rev ff)
> 8GB ram
> fedora 19 64bit
> kicad version 4986 (but the issue is in all prevous versions)
> wxwidgets 3.0.0
> gcc ver. 4.8.2
>
> the problem makes the program unusable.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1339539/+subscriptions
>

[bdien (vl624)]

I use the Gnome (3.12) and Enlightenment(0.19). I recomplie stable version of kicad from gentoo but still same. Maybe the problem is not due to kicad. I'll try switching to a different desktop environment, Thank you

[Fotis Panagiotopoulos (fotis400-mail)]

I have the same problem using Fedora 21 x86_64.

I would like to test with wxWidgets 2.8 but cmake complains: Could NOT find wxWidgets: Found unsuitable version "2.8.12", but required is at least "3.0.0".

How can I change it, so I can compile with wx-2.8?

[Nick Østergaard (nickoe)]

@fotis, wx2.8 is not supported anymore, but the requirement is set in cmake. The commit is somewhat recent, but you can just change the requirement.

[Wayne Stambaugh (stambaughw)]

Please do not assume that if you change the wxWidgets version
requirement to 2.8.12 that it will still compile or run properly. There
are known issues with 2.8 that have been resolved in 3. I haven't built
against 2.8.12 in over a year and we haven't made any effort to keep the
code compatible with 2.8 that I am aware of. wxWidgets 3 or greater
will be a requirement for the next stable release. Your best bet would
be to install wxWidgets 3.0.0 (preferably 3.0.2). If you run into
problems compiling or running with 2.8.12, please do not file bug
reports against it as it is no longer supported in the development branch.

On 1/21/2015 9:47 AM, Nick Østergaard wrote:
> @fotis, wx2.8 is not supported anymore, but the requirement is set in
> cmake. The commit is somewhat recent, but you can just change the
> requirement.
>

[Fotis Panagiotopoulos (fotis400-mail)]

I already tried wxWidgets 3.0.2 and it is not working. Pcbnew has the rendering issues mentioned above.

I was trying just to make it work somehow... Do you have any ideas of solving the issue with wx-3.0.2?

[Nick Østergaard (nickoe)]

@Fotis, I am guessing you are using fedora, right?

[Fotis Panagiotopoulos (fotis400-mail)]

Yes, as already mentioned.

In fact it is the exact same situation as described in the initial bug description.

Any way fixing it? (Or at least using temporarily wx-2.8...)

[Wayne Stambaugh (stambaughw)]

AFAIK, the wxWidgets 3.0.2 drawing issue is related to something the
Fedora windows manager is doing. It works fine on Debian testing and
most of the other Debian derivatives. Some users have found that
changing their windows manager fixes the problem.

If you need to compile with wxWidgets 2.8.12, change line 429 in
CMakeLists.txt from

find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base
xml ${webkitlib} stc REQUIRED )

to

find_package( wxWidgets 2.8.0 COMPONENTS gl aui adv html core net base
xml ${webkitlib} stc REQUIRED )

On 1/21/2015 4:46 PM, Fotis Panagiotopoulos wrote:
> Yes, as already mentioned.
>
> In fact it is the exact same situation as described in the initial bug
> description.
>
> Any way fixing it? (Or at least using temporarily wx-2.8...)
>

[Nick Østergaard (nickoe)]

@Wayne, do you have any references to a fedora that works? I have not heard
of any. It has existed in fedora 20, fedora 21 and the comming fedora 22
(rawhide).

As far as I understand it do not seem to be the window manger or DE, but I
could of course be wrong.

I just wonder if this is some wierd configuration of X or the drivers that
fedora modify like no other.

So if anyone running fedora or similar and the legacy canvas works
perfectly, please schime in.
Den 21/01/2015 23.05 skrev "Wayne Stambaugh" <email address hidden>:

> AFAIK, the wxWidgets 3.0.2 drawing issue is related to something the
> Fedora windows manager is doing. It works fine on Debian testing and
> most of the other Debian derivatives. Some users have found that
> changing their windows manager fixes the problem.
>
> If you need to compile with wxWidgets 2.8.12, change line 429 in
> CMakeLists.txt from
>
> find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base
> xml ${webkitlib} stc REQUIRED )
>
> to
>
> find_package( wxWidgets 2.8.0 COMPONENTS gl aui adv html core net base
> xml ${webkitlib} stc REQUIRED )
>
> On 1/21/2015 4:46 PM, Fotis Panagiotopoulos wrote:
> > Yes, as already mentioned.
> >
> > In fact it is the exact same situation as described in the initial bug
> > description.
> >
> > Any way fixing it? (Or at least using temporarily wx-2.8...)
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1339539
>
> Title:
> pcbnew does not draw correctly the default canvas
>
> Status in KiCad EDA Software Suite:
> New
>
> Bug description:
> Default canvas is not properly drawn, only very confused lines, and at
> different zoom level I see different things.
> The picture attached is an example of what I see.
> In the other canvases the board is drawn properly.
> If I attempt to draw something like tracks nothing is drawn.
>
> Bug verified on two laptop with the following hw:
>
> LAPTOP 1
> core i7
> NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
> 8GB ram
> fedora 20 64bit
> kicad version 4986 (but the issue is in all prevous versions)
> wxwidgets 3.0.0
> gcc ver. 4.8.3
>
> LAPTOP 2
> core i7
> NVIDIA Corporation GK107M [GeForce GT650M] (rev ff)
> 8GB ram
> fedora 19 64bit
> kicad version 4986 (but the issue is in all prevous versions)
> wxwidgets 3.0.0
> gcc ver. 4.8.2
>
> the problem makes the program unusable.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/kicad/+bug/1339539/+subscriptions
>

[Luca Mini (luca-mini-freelance)]

@Nick,
I posted this bug some time ago, and I speak with you about this one, but then nobody seems to be interested in, so I attempt to solve it by myself :D
Actually I have BZR 5379 on fedora 20 working with gnome and wxWidget 3.0.2.
The problem is that I don't remember exactly how I done it :(
I remember that firstly compile kicad with wx 2.8 adn it is working, then I recompile with wx 3.0.2, but using nouveau driver, because with proprietary nvidia driver it doesn't work.
I don't remember other tricky hacking :)

[Miguel Angel Ajo (mangelajo)]

I tried xfce4 (fedora21), with same results.
Also tried disabling 3D acceleration of my hypervisor (testing on a VM) but I can't login after that.

[Martin Errenst (imp-d)]

@bdien: Can you try the following patch? I had the same problem for ages, turns out, somehow, wxgtk is unable to draw circles sometimes without problems (this fails in the demo applications too). The patch is only a workaround for the problem. Not sure if it will change anything on the initially reported problem.

[Wayne Stambaugh (stambaughw)]

@Nick
No, I don't have any confirmed instances of Fedora working other than with 2.8.12. I know there were some Ubuntu issues that were resolved by switching window managers. I don't think we don't have many developers that use Fedora but I could be wrong about that. I've never used it and I'm not in a position to help.

@Luca
Your solution is interesting because I'm using the nvidia proprietary drivers on Debian testing using the Gnome desktop without any issues. Something is obviously different between the two systems. Is it possible one of the new graphics libraries such as wayland is coming into play here? Can someone else with Fedora please confirm if the nouveau driver solves the problem?

@Martin
What video drivers are you using? It would be useful to see if there is any correlation or if it's driver independent. Can someone (everyone?) having the rendering issue test the patch and see if resolves the issue? I would like to see the Fedora rendering issues resolved.

[Martin Errenst (imp-d)]

@Wayne: Normally I use the binary ati driver (x11-drivers/ati-drivers) but also gave the free one (x11-drivers/xf86-video-ati) a try with the same results.

[Wayne Stambaugh (stambaughw)]

On 1/22/2015 12:24 PM, Martin Janitschke wrote:
> @Wayne: Normally I use the binary ati driver (x11-drivers/ati-drivers)
> but also gave the free one (x11-drivers/xf86-video-ati) a try with the
> same results.
>
@Martin: Thanks for the data point. My previous computer had an ATI
video card and I had serious rendering issues with proprietary ATI
driver. I couldn't even get the open source driver to work with my
video card. That being said, it appears that the problem is not video
driver specific since we have nvidia users with similar issues. The
only other thing I can think of is an X.org difference that is causing
the problem.

[jean-pierre charras (jp-charras)]

After some test both on Ubuntu 14.10 and Kubuntu 14.04 LTS, I am now pretty sure this is due to an issue with wxWidgets + gtk3.

If I build wxWidgets (3.0.2) against gtk2 Kicad works fine.
If I build wxWidgets (3.0.2) against gtk3 Kicad does not works.

On gtk3, the wxWidgets --enable-graphics_ctx is always enabled (cannot be disabled).
On gtk3, the wxWidgets --enable-graphics_ctx is not enabled by default.

I never saw the wxWidgets drawing layer working well with the advanced graphics context 2D drawing API in enabled.
A least the XOR mode widely used in Pcbnew and eeschema when moving objects does not work.
On gtk3, looks like very small scaling factors (used in Pcbnew/Gerbview) are not working (certainly a serious bug in wxWidgets/gtk3+advanced graphics context) and few basic draw mode are not working, both on Linux and Windows.

Currently the only one workaround I know is to build wxWidgets using gtk2 (this is the default)

[Wayne Stambaugh (stambaughw)]

On 01/24/2015 08:29 AM, jean-pierre charras wrote:
> After some test both on Ubuntu 14.10 and Kubuntu 14.04 LTS, I am now
> pretty sure this is due to an issue with wxWidgets + gtk3.
>
> If I build wxWidgets (3.0.2) against gtk2 Kicad works fine.
> If I build wxWidgets (3.0.2) against gtk3 Kicad does not works.
>
> On gtk3, the wxWidgets --enable-graphics_ctx is always enabled (cannot be disabled).
> On gtk3, the wxWidgets --enable-graphics_ctx is not enabled by default.
>
> I never saw the wxWidgets drawing layer working well with the advanced graphics context 2D drawing API in enabled.
> A least the XOR mode widely used in Pcbnew and eeschema when moving objects does not work.
> On gtk3, looks like very small scaling factors (used in Pcbnew/Gerbview) are not working (certainly a serious bug in wxWidgets/gtk3+advanced graphics context) and few basic draw mode are not working, both on Linux and Windows.
>
> Currently the only one workaround I know is to build wxWidgets using
> gtk2 (this is the default)
>

JP,

I just finished testing this and yes build wxWidgets against GTK3 seems
to have some very serious issues. I may try disabling the graphics
context to see if thing get any better but the drawing and some of the
control window rendering is broken. I wonder if we are first to
discover this? I will also try building the latest wxWidgets source
from the repo to see if any of the issues have been resolved. Thanks
for figuring this out. We will definitely have to let users know so
they can make the appropriate build decisions.

[bdien (vl624)]

@Martin thank you. I tried the patch and it worked fine including stable version kicad 4017 and kicad live. I've rebuilt the package kicad from fc21 with wxGTK 3.0 it worked fine. When you build the package with kicad live (current) is still the same problem. hope can help solve the problem.

[Terry Barnaby (terry-j)]

Just to confirm JP's report (many thanks for the info :) ).
I am using Fedora21 with KDE. Using default Fedora wxGTK3 libs which use gtk3 all is a mess and nothing really works.

I have built the wxGTK3 rpms with settings to build for gtk2 (named them wxGTK3-gtk2) and then built the latest kicad using this and all appears to works fine, push routing and all.
If it helps anyone I have put our wxGTK3-gtk2 rpms under: http://portal.beam.ltd.uk/dist/fedora_21/beamExtra including the kicad packages I built for our internal use.

Only thing that is not quite right is I have turned of wxPython support as the default Fedora libs use wxGTK for that !

[Nick Østergaard (nickoe)]

2015-01-25 21:04 GMT+01:00 Wayne Stambaugh <email address hidden>:
> On 01/24/2015 08:29 AM, jean-pierre charras wrote:
>> After some test both on Ubuntu 14.10 and Kubuntu 14.04 LTS, I am now
>> pretty sure this is due to an issue with wxWidgets + gtk3.
>>
>> If I build wxWidgets (3.0.2) against gtk2 Kicad works fine.
>> If I build wxWidgets (3.0.2) against gtk3 Kicad does not works.
>>
>> On gtk3, the wxWidgets --enable-graphics_ctx is always enabled (cannot be disabled).
>> On gtk3, the wxWidgets --enable-graphics_ctx is not enabled by default.
>>
>> I never saw the wxWidgets drawing layer working well with the advanced graphics context 2D drawing API in enabled.
>> A least the XOR mode widely used in Pcbnew and eeschema when moving objects does not work.
>> On gtk3, looks like very small scaling factors (used in Pcbnew/Gerbview) are not working (certainly a serious bug in wxWidgets/gtk3+advanced graphics context) and few basic draw mode are not working, both on Linux and Windows.
>>
>> Currently the only one workaround I know is to build wxWidgets using
>> gtk2 (this is the default)
>>
>
> JP,
>
> I just finished testing this and yes build wxWidgets against GTK3 seems
> to have some very serious issues. I may try disabling the graphics
> context to see if thing get any better but the drawing and some of the
> control window rendering is broken. I wonder if we are first to
> discover this? I will also try building the latest wxWidgets source
> from the repo to see if any of the issues have been resolved. Thanks
> for figuring this out. We will definitely have to let users know so
> they can make the appropriate build decisions.

Hi Wayne,

Did you get any further on this?

I have just tried to rebuild wxgtk on Archlinux with gtk3 3.14.8,
whilst on fedora 20 the gtk3 is 3.10.9. I can confirm that the issue
appears. Also to note, is thet the eeschema canvas seem antialised
when using gtk3, and it renders slower when zooming. And the issue
with drawing wires blindly exists, this is also when moving objects.

So just for reference it is confirmed that this issue is seen on
fedora, ubuntu, gentoo and archliux if using --with=gtk3 for the wxgtk
package.

Also, Miguel Ajo has updated the fedora copr builds to use gtk2, hence
if anyone on fedora stating it magically works... it is not so
magical.

[Wayne Stambaugh (stambaughw)]

On 2/14/2015 3:03 PM, Nick Østergaard wrote:
> 2015-01-25 21:04 GMT+01:00 Wayne Stambaugh <email address hidden>:
>> On 01/24/2015 08:29 AM, jean-pierre charras wrote:
>>> After some test both on Ubuntu 14.10 and Kubuntu 14.04 LTS, I am now
>>> pretty sure this is due to an issue with wxWidgets + gtk3.
>>>
>>> If I build wxWidgets (3.0.2) against gtk2 Kicad works fine.
>>> If I build wxWidgets (3.0.2) against gtk3 Kicad does not works.
>>>
>>> On gtk3, the wxWidgets --enable-graphics_ctx is always enabled (cannot be disabled).
>>> On gtk3, the wxWidgets --enable-graphics_ctx is not enabled by default.
>>>
>>> I never saw the wxWidgets drawing layer working well with the advanced graphics context 2D drawing API in enabled.
>>> A least the XOR mode widely used in Pcbnew and eeschema when moving objects does not work.
>>> On gtk3, looks like very small scaling factors (used in Pcbnew/Gerbview) are not working (certainly a serious bug in wxWidgets/gtk3+advanced graphics context) and few basic draw mode are not working, both on Linux and Windows.
>>>
>>> Currently the only one workaround I know is to build wxWidgets using
>>> gtk2 (this is the default)
>>>
>>
>> JP,
>>
>> I just finished testing this and yes build wxWidgets against GTK3 seems
>> to have some very serious issues. I may try disabling the graphics
>> context to see if thing get any better but the drawing and some of the
>> control window rendering is broken. I wonder if we are first to
>> discover this? I will also try building the latest wxWidgets source
>> from the repo to see if any of the issues have been resolved. Thanks
>> for figuring this out. We will definitely have to let users know so
>> they can make the appropriate build decisions.
>
> Hi Wayne,
>
> Did you get any further on this?

My testing has confirmed that building wxWidgets and wxPython against
gtk3 is a dead end at the moment. There is no easy path to making this
work. It will require a lot of code changes on our part or bug fixing
on wxWidgets developers part. Thankfully, Debian has chosen to stick
with gtk2. Maybe they found the issues we are now seeing with other
distros and decided sticking with gtk2 would be prudent at this time. I
would be more than happy to test patches to fix the gtk3 issues if
someone has the time. As of right now, I'm recommending to all of the
package devs use gtk2 when build wxWidgets and wxPython if you want to
keep KiCad usable. I know this is less than desirable but we just don't
have the time to fix it right now.

>
> I have just tried to rebuild wxgtk on Archlinux with gtk3 3.14.8,
> whilst on fedora 20 the gtk3 is 3.10.9. I can confirm that the issue
> appears. Also to note, is thet the eeschema canvas seem antialised
> when using gtk3, and it renders slower when zooming. And the issue
> with drawing wires blindly exists, this is also when moving objects.
>
> So just for reference it is confirmed that this issue is seen on
> fedora, ubuntu, gentoo and archliux if using --with=gtk3 for the wxgtk
> package.
>
> Also, Miguel Ajo has updated the fedora copr builds to use gtk2, hence
> if anyone on fedora stating it magically works... it is not so
> magical.
...

[Nick Østergaard (nickoe)]

I downgrade the importance of this bug, becaue the library combinations that triggers this issues is not directly or only kicad, presumeably. This is not worth wating energy on until "the release".

[Stefan (stol)]

This might be a shoot in the dark, but I have experienced some problems with wxwidget 3.0.2 when I compiled and used the debug version of wxWidget. One thing is that the preview window got all black (similar to your first screen shoot)

PS
I compiled wxWidget like this
../../configure --enable-unicode --enable-debug --enable-debug_info --enable-debug_gdb
DS

[Bryant (bryant-mairs)]

Has this problem been reported upstream to wxwidgets? I'm a Fedora user that can't use prebuilt Kicad because of this so I'd like to help debug and fix this issue. I figured reporting this upstream is the next step.

[Wayne Stambaugh (stambaughw)]

To my knowledge, the problem has not been reported. The wxWidgets folks
will want a minimal code sample that shows the problem and I don't have
the time to create one. wxWidgets devs most likely will not compile all
of KiCad to debug their problem. If someone has the time to create a
sample and file a bug report against wxWidgets, I would appreciated it.

I believe the fedora packages we provide are built with a custom
wxWidgets using gtk2 rather than gtk3 so you may want to try that.

On 11/29/2015 9:00 PM, Bryant wrote:
> Has this problem been reported upstream to wxwidgets? I'm a Fedora user
> that can't use prebuilt Kicad because of this so I'd like to help debug
> and fix this issue. I figured reporting this upstream is the next step.
>

[Maciej Suminski (orsonmmz)]

I do not think this is something we actually plan to fix. As far as I can tell, the plan is to drop the legacy canvas and leave only the modern ones.

[Seth Hillbrand (sethh)]

I think this is where we were collecting all of our gtk2/gtk3 issues. If we close this one, let's unlink the duplicates

[Jeff Young (jeyjey)]

Were the duplicate issues actually different, or just separate reports of the same thing?

[Seth Hillbrand (sethh)]

Separate issues that will (probably) be resolved once we switch to GTK3. Crashes/mismatched libs, scrambled images and the like.

[Nick Østergaard (nickoe)]

I think we can consider this fix committed as the gal stuff has made it into the master branch targeted to 5.1.