Discussion:
Bug#934385: wxDC::Clear() doesn't work if wxWidgets uses GTK3
(too old to reply)
Olly Betts
2019-08-11 22:10:02 UTC
Permalink
Control: tag -1 unreproducible
If a draw context is used and wxWidgets 3.0 (3.1 isn't affected, but
isn't packaged with debian as it is the development version) uses GTK3
the background is likely not to be cleared before a redraw as
wxDC::Clear() doesn't work under these circumstances.
I tried to reproduce your bug by patching the drawing sample in the wx
source code using the attached patch, but it seems to work fine for me.

If you cd to the drawing subdirectory and run:

make -f makefile.unx WX_PORT=gtk3

Then double-check that it's linked to the GTK3 version:

ldd drawing|grep libwx_gtk

And then run it:

./drawing

This prints "Clear()" to the console (so we are running the patched
code) but the window doesn't have a hatching on the background. If
you remove the dc.Clear() just after where I've patched and rerun
the make command above then the window has hatching over it. So
clearly wxDC::Clear() is working in this case.

So I'm afraid I don't seem to be able to reproduce your problem.

Please can you come up with a small reproducer (upstream like a patch
against one of their samples) and file a bug upstream?

Cheers,
Olly
Scott Talbert
2019-08-12 03:30:01 UTC
Permalink
Post by Olly Betts
If a draw context is used and wxWidgets 3.0 (3.1 isn't affected, but
isn't packaged with debian as it is the development version) uses GTK3
the background is likely not to be cleared before a redraw as
wxDC::Clear() doesn't work under these circumstances.
I tried to reproduce your bug by patching the drawing sample in the wx
source code using the attached patch, but it seems to work fine for me.
make -f makefile.unx WX_PORT=gtk3
ldd drawing|grep libwx_gtk
./drawing
This prints "Clear()" to the console (so we are running the patched
code) but the window doesn't have a hatching on the background. If
you remove the dc.Clear() just after where I've patched and rerun
the make command above then the window has hatching over it. So
clearly wxDC::Clear() is working in this case.
So I'm afraid I don't seem to be able to reproduce your problem.
Please can you come up with a small reproducer (upstream like a patch
against one of their samples) and file a bug upstream?
Gunter did file a bug upstream:
https://trac.wxwidgets.org/ticket/18463

However, Olly's request about making a reproducer still stands.

Gunter - also - what desktop environment are you using (e.g., Gnome, KDE,
XFCE, etc.). And are you running on X11 or Wayland?

Scott
Olly Betts
2019-08-12 04:50:02 UTC
Permalink
Control: forwarded -1 https://trac.wxwidgets.org/ticket/18463
Post by Scott Talbert
Post by Olly Betts
So I'm afraid I don't seem to be able to reproduce your problem.
Please can you come up with a small reproducer (upstream like a patch
against one of their samples) and file a bug upstream?
https://trac.wxwidgets.org/ticket/18463
If you file an upstream bug too, please mark the Debian bug as forwarded
to it, or if you don't know how, at least mention the upstream bug.
Otherwise you have us wasting effort, which is rather disrespectful of
our time.

Cheers,
Olly
Olly Betts
2019-09-16 21:10:01 UTC
Permalink
The upstream bug has been closed as invalid - the problem here is
incorrect use of the wxWidgets API - Clear() uses the brush used by
SetBackground() not the brush set by SetBrush(). Therefore I'm closing
this bug as invalid too.
Gunter: You'll need to fix the code in wxmaxima to call SetBackground()
with the brush you want Clear() to use.
wxMaxima already did use SetBackground() when it used Clear(). I don't
know if the GTK version debian uses or in the wxWidgets version debian
ships is the cause for this not to helo.
The current release of wxMxima no more uses Clear() on GTK3. My program
therefore no more is affected by the bug. Therefore won't object against
closing the bug. But chances are high that other projects are still
affected.
Upstream closed the bug based on the patch you sent to the list, which
was invalid in the way I describe:

https://trac.wxwidgets.org/ticket/18463#comment:4

Independently, I had previously tried to reproduce based on just your
description, and was unable to.

Maybe there is still a bug here, but if so you really need to provide a
valid reduced testcase to demonstrate it:

https://trac.wxwidgets.org/wiki/HowToSubmitTicket#ReproducingtheProblem

Given such a way to reproduce a bug, upstream have a very good track
record for resolving it, but bug reports that require someone to try to
reproduce the situation from a description tend to just languish
(upstream already have nearly 2000 open tickets, most of which have
no clear way to reproduce provided).

So if you want to get a wx bug fixed, the key thing is to provide a
reduced way to reproduce it, ideally as a patch against one of the
samples.

Cheers,
Olly

Scott Talbert
2019-08-12 14:30:01 UTC
Permalink
Post by Scott Talbert
Post by Olly Betts
If a draw context is used and wxWidgets 3.0 (3.1 isn't affected, but
isn't packaged with debian as it is the development version) uses GTK3
the background is likely not to be cleared before a redraw as
wxDC::Clear() doesn't work under these circumstances.
I tried to reproduce your bug by patching the drawing sample in the wx
source code using the attached patch, but it seems to work fine for me.
make -f makefile.unx WX_PORT=gtk3
ldd drawing|grep libwx_gtk
./drawing
This prints "Clear()" to the console (so we are running the patched
code) but the window doesn't have a hatching on the background.  If
you remove the dc.Clear() just after where I've patched and rerun
the make command above then the window has hatching over it.  So
clearly wxDC::Clear() is working in this case.
So I'm afraid I don't seem to be able to reproduce your problem.
Please can you come up with a small reproducer (upstream like a patch
against one of their samples) and file a bug upstream?
https://trac.wxwidgets.org/ticket/18463
However, Olly's request about making a reproducer still stands.
Gunter - also - what desktop environment are you using (e.g., Gnome,
KDE, XFCE, etc.).  And are you running on X11 or Wayland?
Gnome on Wayland; For wxMaxima (the package I maintain myself) after
receiving the first screen shots with a background that clearly showed
that Clear() is't worked (none of the affected users complained about
this problem, as its symptoms aren't too bad for this specific program)
I have introduced a workaround: I paint a solid rectangle in the
background on gtk3 instead of calling Clear() => If this bug is closed
as "can't reproduce" I won't be angry.
Does the problem happen when running on X11? You can force X11 by setting
environment variable:

GDK_BACKEND=x11

before starting your program.

Scott
Scott Talbert
2019-08-12 16:40:01 UTC
Permalink
Does the problem happen when running on X11?  You can force X11 by
    GDK_BACKEND=x11
before starting your program.
GDK_BACKEND was already set to x11 due to my debugging. If I unset the
environment variable the problem disappears => Logged in into a
non-wayland session and the problem appeared again.
OK, so just to confirm: the problem occurs with X11 but NOT with Wayland?

Scott
Olly Betts
2019-08-12 18:10:01 UTC
Permalink
Post by Scott Talbert
GDK_BACKEND was already set to x11 due to my debugging. If I unset the
environment variable the problem disappears => Logged in into a
non-wayland session and the problem appeared again.
OK, so just to confirm: the problem occurs with X11 but NOT with Wayland?
If so, there's clearly more to it that just wxDC::Clear() not working
under X11 with GTK3 - I'm not running wayland and my patched drawing
sample showed wxDC::Clear() working.

Cheers,
Olly
Loading...