wxGLCanvas: Discrete Colour Sections Instead of Smooth Colour Gradient about wxwidgets HOT 15 OPEN

Downgrading the kwin package to 6.0.2 fixed the problem. Versions 6.0.3 and 6.0.3.1 have the problem.

from wxwidgets.

Sorry, I have absolutely no idea what could explain this, but I wonder if it's specific to EGL implementation or also happens when using GLX? Unfortunately testing this requires rebuilding wxWidgets with --disable-glcanvasegl configure option or wxUSE_GLCANVAS_EGL=OFF if using CMake.

from wxwidgets.

Yes, I recompiled wxWidgets with --disable-glcanvasegl and ran them with export GDK_BACKEND=x11 which rendered correctly. In fact recompiling was not necessary, the archlinux packaged version of wxWidgets correctly renders when using x11.

from wxwidgets.

Thanks for testing! But now that we know it's EGL-specific, I can't help asking another question: does GLFW example work correctly when using EGL?

from wxwidgets.

I believe it was using EGL, how should i determine that?

from wxwidgets.

I believe it was using EGL, how should i determine that?

Not sure how to do it with GLFW. If it uses Wayland, it must be using EGL (GLX can't work in this case), does it?

from wxwidgets.

I used the xprop and xeyes tools to test, and the glfw program is indeed using Wayland/EGL.
https://superuser.com/questions/1484068/how-to-check-if-a-program-uses-wayland-or-x11-in-linux.

from wxwidgets.

Thanks again for testing!

Unfortunately I still don't know what's actually wrong here, my guess is that we are not setting some attributes correctly but unfortunately I don't have time to look at this further and any help would be welcome.

from wxwidgets.

@vadz Didn't you fix something with selecting the first "context" available which was only 4bits per color channel recently.

That could explain this, i.e. to small color space would cause banding I think.

(just scrolling by the mailing list)

from wxwidgets.

Oops, yes, indeed, thanks for the reminder, I hadn't thought that choosing a wrong mode could result in this, but it definitely could.

@ReuBird23 Can you please test the latest master or 3.2 with #24375 (which will soon be merged into it too and be part of 3.2.5)?

from wxwidgets.

I tested it, and it made no change.
However, I have just had the opportunity to test the problem on my desktop that I have been away from for a few weeks (I have been having the issues on my laptop). The banding problem didn't happen...until after I updated my system. The wxWidgets-gtk3 was already up to date beforehand, so some other update on my system within the last month has caused the problem. I will do some downgrading to try to find out which package it is.

from wxwidgets.

Try adding
WX_GL_MIN_RED, 8, WX_GL_MIN_GREEN, 8, WX_GL_MIN_BLUE, 8
to wxGLCanvas attributes.

Looks like it uses RGB565 mode.

from wxwidgets.

And GLFW has special code to pick the config closest to RGB(A)888(8) by default:

https://github.com/glfw/glfw/blob/228e58262e18f2ee61799bd86d0be718b1e31f9f/src/window.c#L282-L289

https://github.com/glfw/glfw/blob/228e58262e18f2ee61799bd86d0be718b1e31f9f/src/context.c#L183

from wxwidgets.

Yes thank you, that works. I wonder what changed in the kwin update that meant it wasn't necessary before. Thanks for your help.

from wxwidgets.

Thanks for the hint, Alex!

I wonder if we should we select 8-bit colour channels by default too? It seems that if anybody really wants less, they would be selecting this explicitly anyhow...

If not, this can be just closed.

from wxwidgets.