Created attachment 135348 [details]
before this commit there were problems with supertuxkart but i did build mesa with the v2 of the patch and everything was fine. after the patch landed i decided to rebuild mesa without the patch and this happened:
Created attachment 135352 [details]
it also happens in the configuration
It is not clear from the bug description if these screenshots are taken with or without mentioned commit. Are these taken with latest Mesa master?
Also, did you install the built Mesa in your system (replace existing i965_dri.so) or did you run test with LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH?
it is from latest git so that commit is included,
i build mesa with a pkgbuild on archlinux so it's a fresh install
i suspect the v3 of the patch(what has landed) has the issue as the v2 that i applied worked fine.
it could also be another commit but it seems unlikely
ok thanks I will try to reproduce and figure out what could be going wrong here
btw im using stk 0.9.3rc1 from archlinux
Could you post the stdout.log file from ~/.config/supertuxkart/0.8.2? The glxinfo output may be usefull too.
It looks that in your case STK still uses the ugly hack with alpha_channel=true to force srgb-capable framebuffer. And the compositor for some reason doesn't make the window opaque. Actually it never happened for me on xserver... For wayland there is wl_surface_set_opaque_region. I will try to reproduce it with current git mesa.
Cannot reproduce on Gnome :( I tried both xserver and xwayland.
Created attachment 135357 [details]
Created attachment 135358 [details]
So the srgb patch seems to work fine. STK doesn't complain about framebuffer that is not srgb-capable, it doesn't use the alpha_channel=true hack, and also glxinfo shows some configs with srgb framebuffers.
I suppose that something in your compositor/window manager was changed. And actually I would like to find a way to reproduce it, so that I can fix it in STK.
Maybe we need a wl_surface_set_opaque_region equivalent for x11 to be 100% correct...
(In reply to Deve from comment #12)
> So the srgb patch seems to work fine. STK doesn't complain about framebuffer
> that is not srgb-capable, it doesn't use the alpha_channel=true hack, and
> also glxinfo shows some configs with srgb framebuffers.
> I suppose that something in your compositor/window manager was changed. And
> actually I would like to find a way to reproduce it, so that I can fix it in
> Maybe we need a wl_surface_set_opaque_region equivalent for x11 to be 100%
im using gnome shell 3.26 on xorg
it also happens on windowed mode
Created attachment 135361 [details]
on windowed mode and on top of firefox
I could not reproduce this on FC26 with gnome-shell 3.24.3 and supertuxkart 0.9.2.
If you have enough skills, you can try to set _NET_WM_OPAQUE_REGION to whole window size using xprop.
I made some experiments with rgba windows and setting opaque region with netwm works fine under Gnome. You can check if it works for you when game is started:
xprop -name SuperTuxKart -f _NET_WM_OPAQUE_REGION 32c -set _NET_WM_OPAQUE_REGION 0,0,$width,$height
Replace $width and $height with proper values.
And if it works for you, then I will just set this property during window creation in STK.
(In reply to Deve from comment #18)
> I made some experiments with rgba windows and setting opaque region with
> netwm works fine under Gnome. You can check if it works for you when game is
> xprop -name SuperTuxKart -f _NET_WM_OPAQUE_REGION 32c -set
> _NET_WM_OPAQUE_REGION 0,0,$width,$height
> Replace $width and $height with proper values.
> And if it works for you, then I will just set this property during window
> creation in STK.
it works !
but if i apply new resolution it starts to have transparency again
Ok, it should work now:
(In reply to Deve from comment #20)
> Ok, it should work now:
good to know
is it gonna be pushed for 0.9.3rc2 or final?
also i would like to see the mesa part fixed soon :)
(In reply to david becerra from comment #22)
> also i would like to see the mesa part fixed soon :)
It seems very unlikely that there is any bug in Mesa considering this issue. Bisected Mesa change exposes additional visuals for applications to use and does not change existing visuals behaviour. I will leave this bug open for now in case there will be more similar/same bug reports but it will be soon resolved as NOTOURBUG if no such reports arrive and we are not able to reproduce the failure.
The main reason is that probably alpha blending is somewhere messed in STK. It shouldn't produce semi-transparent image...
It was happening for me on wayland when I was creating EGL context with alpha channel. And that's why I added wl_surface_set_opaque_region.
So there may be two reasons:
- Current Gnome+xserver now behaves the same as Gnome+wayland
- Mesa now uses alpha channel even if we didn't request it
But again, I can't reproduce it with Intel HD 4000 and Gnome 3.24.
this is fixed on stk 0.9.3
and no other game shows this behaviour
I haven't been able to reproduce this after following commit landed to Xorg and I haven't received any new bugs on this subject. Resolving as fixed, please reopen if this still occurs.
--- 8< ---
Author: Tapani Pälli <email@example.com>
Date: Tue Nov 28 09:23:29 2017 +0200
glx: do not pick sRGB config for 32-bit RGBA visual
This fixes blending issues seen with kwin and gnome-shell when
32bit visual has sRGB capability set.
Reviewed-by: Adam Jackson <firstname.lastname@example.org>
Signed-off-by: Tapani Pälli <email@example.com>