Software rendering incorrectly compositing fullscreen windows on E 0.25.0+ #14

Open
opened 1 year ago by dsmccombs · 7 comments

Beginning with the 0.25.0 release of enlightenment, and tested to be continuing on 0.25.3, fullscreen windows appear to composited, or are otherwise running extremely slowly when the Compositor Engine is set to Software with Don't composite fullscreen windows enabled. Changing the Compositor to OpenGL or downgrading to enlightenment 0.24.2 and using the Software renderer works as expected.

Test configuration:

  • Up-to-date Archlinux
  • xorg 21.1.4
  • 3840x2160 resolution
  • Running different full screen games via WINE such as Myst 2021 or Diablo II: Resurrected
  • Upgrading/downgrading between enlightenment-0.25.3-1-x86_64.pkg.tar.zst and enlightenment-0.24.2-1-x86_64.pkg.tar.zst packages

Using xprop to view the properties of the full screen window between the different versions of enlightenment, _NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 1 is set in both cases, the only noteable difference is __E_ATOM_E_WAS_HERE(CARDINAL) = 1 being set on the newer version of enlightenment where this issue occurs.

I don't have exact metrics to list, but can say that these games are smooth and playable with the Compositor Engine set to Software with Don't composite fullscreen windows enabled on 0.24.2, and are basically a 1FPS slideshows on 0.25.0+. Disabling Don't composite fullscreen windows on 0.24.2 produces the same results, which is why I think that setting is not being honored on 0.25.0+.

Happy to provide any other information that would be useful if asked.

Beginning with the 0.25.0 release of enlightenment, and tested to be continuing on 0.25.3, fullscreen windows appear to composited, or are otherwise running extremely slowly when the Compositor Engine is set to Software with `Don't composite fullscreen windows` enabled. Changing the Compositor to OpenGL or downgrading to enlightenment 0.24.2 and using the Software renderer works as expected. Test configuration: - Up-to-date Archlinux - xorg 21.1.4 - 3840x2160 resolution - Running different full screen games via WINE such as Myst 2021 or Diablo II: Resurrected - Upgrading/downgrading between `enlightenment-0.25.3-1-x86_64.pkg.tar.zst` and `enlightenment-0.24.2-1-x86_64.pkg.tar.zst` packages Using `xprop` to view the properties of the full screen window between the different versions of enlightenment, `_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 1` is set in both cases, the only noteable difference is `__E_ATOM_E_WAS_HERE(CARDINAL) = 1` being set on the newer version of enlightenment where this issue occurs. I don't have exact metrics to list, but can say that these games are smooth and playable with the Compositor Engine set to Software with `Don't composite fullscreen windows` enabled on 0.24.2, and are basically a 1FPS slideshows on 0.25.0+. Disabling `Don't composite fullscreen windows` on 0.24.2 produces the same results, which is why I think that setting is not being honored on 0.25.0+. Happy to provide any other information that would be useful if asked.
raster self-assigned this 1 year ago
Owner

Hmmm... there must be a reason - something is overlayed and the window is not the only thing on screen... what - i don't know.

Hmmm... there must be a reason - something is overlayed and the window is not the only thing on screen... what - i don't know.
Poster

I was wrong about the OpenGL compositor not presenting this problem in 0.25.0+, it's just different in that some games end up as a black screen rather than showing anything, furiously alt+tab'ing to shuffle windows around can sometimes get the game to play normally but it's not very consistent.

I did some git bisecting this morning, and narrowed it down to this commit:

f8721df53a

If I revert that on current master, these games play correctly full screen at full speed like they had in 0.24.2.

I think you're right in that however these games launch in Wine via Lutris there's some other unseen window confusing things with the change in the above commit.

I was wrong about the OpenGL compositor not presenting this problem in 0.25.0+, it's just different in that some games end up as a black screen rather than showing anything, furiously alt+tab'ing to shuffle windows around can sometimes get the game to play normally but it's not very consistent. I did some git bisecting this morning, and narrowed it down to this commit: https://git.enlightenment.org/enlightenment/enlightenment/commit/f8721df53a23566580dcde4b0f2b4b0c02dc4d03 If I revert that on current master, these games play correctly full screen at full speed like they had in 0.24.2. I think you're right in that however these games launch in Wine via Lutris there's some other unseen window confusing things with the change in the above commit.
Poster

Hmm.. the games I've had this issue with all show some sort of splash screen/logo in a separate window before the game launches, maybe that's somehow getting caught up in that change.

Hmm.. the games I've had this issue with all show some sort of splash screen/logo in a separate window before the game launches, maybe that's somehow getting caught up in that change.
Owner

thanks for the bisect. that helps as at least from my quick tests with fullscreen windows in general showed it to work. so specific to wine/lutris or that scenario. now that change takes override-redirect windows (used for poup menus by apps) and make them appear ABOVE apps... so some override-redirect window is hobvering on top somewhere. maybe 1x1 pixel in a corner... i dont' know actually. i need to narrow that down, but it's this presence of that window causing compositing to stay on. now it may be that we are promoting a window that is below... to above. this i have to look into - i need to reproduce this to see what's going on under the hood x11 window-wise

thanks for the bisect. that helps as at least from my quick tests with fullscreen windows in general showed it to work. so specific to wine/lutris or that scenario. now that change takes override-redirect windows (used for poup menus by apps) and make them appear ABOVE apps... so some override-redirect window is hobvering on top somewhere. maybe 1x1 pixel in a corner... i dont' know actually. i need to narrow that down, but it's this presence of that window causing compositing to stay on. now it may be that we are promoting a window that is below... to above. this i have to look into - i need to reproduce this to see what's going on under the hood x11 window-wise
Poster

@raster is there a command I could run to get a list of all windows and their attributes while it's happening that would be useful for you?

Also, since issue tracking was switched over to this system I'm not getting any notification emails of replies even though I'm subscribed to this issue. Is it just me? I'm only noticing your replies if I happen to look at the issue.

@raster is there a command I could run to get a list of all windows and their attributes while it's happening that would be useful for you? Also, since issue tracking was switched over to this system I'm not getting any notification emails of replies even though I'm subscribed to this issue. Is it just me? I'm only noticing your replies if I happen to look at the issue.
Owner

you can use xwininfo -tree -root
then xwininfo -id 0x.....
and xprop -id 0x.....

the id's will come from the first command to poke in some more... :) and yeah -i don't get emails either. thus why things sit around for a while. i don't know why.

you can use xwininfo -tree -root then xwininfo -id 0x..... and xprop -id 0x..... the id's will come from the first command to poke in some more... :) and yeah -i don't get emails either. thus why things sit around for a while. i don't know why.
Poster

Attached is the output of xwininfo -id 0x... and xprop -id 0x... of all windows returned by xwininfo -tree -root while running Myst 2021 fullscreen on Enlightenment 0.25.4 with the problem presenting itself. I collected the info via a script I ran with a 30 second delay before I opened the game to ensure that the game was still the top window when xwininfo/xprop ran.

I kept open windows minimal (from a user perspective, just lutris, terminology, Myst itself, and the network manager applet). Running the same setup with a patched Enlightenment that reverts that commit I linked earlier allows the game to run at full speed.

Attached is the output of xwininfo -id 0x... and xprop -id 0x... of all windows returned by xwininfo -tree -root while running Myst 2021 fullscreen on Enlightenment 0.25.4 with the problem presenting itself. I collected the info via a script I ran with a 30 second delay before I opened the game to ensure that the game was still the top window when xwininfo/xprop ran. I kept open windows minimal (from a user perspective, just lutris, terminology, Myst itself, and the network manager applet). Running the same setup with a patched Enlightenment that reverts that commit I linked earlier allows the game to run at full speed.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: enlightenment/enlightenment#14
Loading…
There is no content yet.