Gui duplicated when not full screen (regression in 3.2.4 beta 1) [Linux, Optimus]

[git2013vb]

Godot version:

3.3 mono stable

OS/device including version:

Debian 10 x11

Issue description:

When not full screen When I try to resize the window

I guess I need to roll back to 3.2.3?

Steps to reproduce: See before

Minimal reproduction project:

NA

[Zireael07]

Can't reproduce on Manjaro, I guess this is something in your gfx card drivers?

[Calinou]

@git2013vb Which graphics card model and driver are you using?

[git2013vb]

Its a nvidia card 01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 650M] (rev a1) I use optirun It work fine in 3.2.3 this is my launcher optirun -v /home/vale/Downloads/godot_mono/Godot_v3.2.3-stable_mono_x11_64/Godot_v3.2.3-stable_mono_x11.64 %f

if I don't use optirun it work, but optirun allow me to run it in my nvidia card without optirun it work with my intel card - if I can't run godot in GPU this will became an issue: OpenGL ES 3.0 Renderer: Mesa DRI Intel(R) Ivybridge Mobile

this issue is related to #47719

[git2013vb]

Hi, I think this too is a regression. btw Using 3.4 beta2 still I have the problem.

[Calinou]

@git2013vb Can you try to bisect the regression to determine the exact commit on which this issue started happening?

You can also download and test the 3.2.4 betas/RCs individually, then test the 3.3 RCs. (3.2.4 was renamed to 3.3 during its development cycle.)

[git2013vb]

I checked, It starts since 3.2.4 beta1 (https://downloads.tuxfamily.org/godotengine/3.2.4/beta1/mono/) Thanks

[akien-mga]

Thanks, that helps narrow it down!

Relevant changes between 3.2.3-stable and 3.2.4 beta 1 (2e073ecbeaf5b502c2b8c3c0510e4a22a56db58f) for platform/x11:

$ git log 3.2.3-stable..2e073ecbeaf5b502c2b8c3c0510e4a22a56db58f platform/x11

commit 04fb41a0f37c884b8afdc44d4a38f2d99e78fa90
Merge: f442dc062a 1ea7358405
Author: Rémi Verschelde <rverschelde@gmail.com>
Date:   Tue Oct 20 13:27:07 2020 +0200

    Merge pull request #42531 from BastiaanOlij/add_get_native_handle

    Add get native handle

commit 1ea7358405d9d98dac2e2a9c0acd563be4d68e17
Author: Bastiaan Olij <mux213@gmail.com>
Date:   Sat Oct 3 22:13:39 2020 +1000

    Add get_native_handle to OS

commit c2290dbedd00e72b943f65a55386dc9f119401e9
Author: lawnjelly <lawnjelly@gmail.com>
Date:   Wed Oct 14 08:32:05 2020 +0100

    Unified GLES2 / GLES3 Batching

    Batching is mostly separated into a common template which can be used with multiple backends (GLES2 and GLES3 here). Only necessary specifics are in the backend files.

    Batching is extended to cover more primitives.

commit 1815a90796b00ebf51604c1a0bbcb81a8390dce6
Merge: beda69888f 936c701838
Author: Rémi Verschelde <rverschelde@gmail.com>
Date:   Thu Oct 1 19:10:30 2020 +0200

    Merge pull request #42466 from nekomatata/x11-events-mutex-leak

    [3.2] Fix leak with events mutex in OS_X11

commit 936c7018382507bf022c2f66161b209bc31abf90
Author: PouleyKetchoupp <pouleyketchoup@gmail.com>
Date:   Thu Oct 1 16:16:23 2020 +0200

    Fix leak with events mutex in x11 Display Server

commit 4ad74609ced8f21e266c8102498ec5c1c7c94831
Merge: 3961f50176 e51fed9d1b
Author: Rémi Verschelde <rverschelde@gmail.com>
Date:   Thu Oct 1 13:58:24 2020 +0200

    Merge pull request #40205 from bruvzg/click-through-3

    [3.2] Add mouse event pass-through support for window.

commit 0c3e0ab1949e18c22ecf7729680c396b07e9b5a0
Merge: 9da889ff29 abd7c1833e
Author: Rémi Verschelde <rverschelde@gmail.com>
Date:   Thu Oct 1 13:56:09 2020 +0200

    Merge pull request #40994 from qarmin/sanitization32

    [3.2] Added Linux sanitizer with xvfb to github workspace

commit 904773149d0f7ea6b71d532c5332bcf6ba6335b5
Merge: 59d873258c f725d9cb73
Author: Rémi Verschelde <rverschelde@gmail.com>
Date:   Wed Sep 30 16:39:55 2020 +0200

    Merge pull request #42341 from nekomatata/x11-events-thread-3.2

    [3.2] Fix issues related to delay when processing events on Linux

commit f725d9cb733e103c91d889777b78c5a646095658
Author: PouleyKetchoupp <pouleyketchoup@gmail.com>
Date:   Fri Sep 25 18:16:39 2020 +0200

    Fix issues related to delay when processing events on Linux

    3.2 backport of PR #41910:
    Fix general keyboard input lag on X11 display server
    Fix delay to process clipboard content from Godot in other programs

commit 8b5061aae70d5eef7332677bfd78baab4247dcdf
Author: Rémi Verschelde <rverschelde@gmail.com>
Date:   Fri Sep 18 11:55:12 2020 +0200

    X11: Try to load libXrandr.so.3 if libXrandr.so.2 isn't found

    All Linux distros, and FreeBSD and OpenBSD seem to have libXrandr.so.2,
    but for some reason recent NetBSD versions seem to have libXrandr.so.3 now.

    (cherry picked from commit 413ff7938df54c6c0bf6dc3ecd86c2c713f6f43a)

commit cb78a5d7ae62963d386282e8ba70a369629a0ec2
Author: Rémi Verschelde <rverschelde@gmail.com>
Date:   Fri Sep 18 08:27:02 2020 +0200

    Linux/BSD: Fix support for NetBSD

    Add __NetBSD__ to `platform_config.h` so that it can find `alloca`
    and use the proper `pthread_setname_np` format.

    Rename RANDOM_MAX to avoid conflict with NetBSD stdlib.

    Fixes #42145.

    (cherry picked from commit 5f4d64f4f3ca633a147eda995ab6613a446a4f0e)

commit e51fed9d1bac040196c53a5840638fa886aa1d13
Author: bruvzg <7645683+bruvzg@users.noreply.github.com>
Date:   Mon Jun 29 12:31:13 2020 +0300

    [3.2] Add window click-through support.

commit abd7c1833ec57eaf831270de2153077edb1eb914
Author: Rafał Mikrut <mikrutrafal@protonmail.com>
Date:   Fri Aug 14 12:15:58 2020 +0200

    Added Linux sanitizer with xvfb to github workspace

I'm thinking either window click-through or event processing fixes may be related? @pouleyKetchoupp @bruvzg

[git2013vb]

I will add an error' screenshot. Maybe this info can help..

and the log file mentioned in the error: 2021_07_30 14.00.06 (12364).txt

[git2013vb]

v3.3.3.stable.mono.official [b973f997f] affected too.

[git2013vb]

using v3.4.beta4.mono.official [6a058cbf3] Debian 11

I tried to run a exported project (multiplayer game and I need to test more than one instance at time - I need to use nvidia card ) under nvidia card using optirun - like before mentioned - and I still have the problem

Also if I have godot editor open I can't run any other programs that use optirun.

Any eta please? I can't use godot engine in this conditions. :) Thanks

[Calinou]

• Try using primusrun instead of optirun. It generally performs better.
• Bumblebee is considered deprecated by now. NVIDIA's built-in PRIME support should be used instead, no latter how inconvenient it may be. It's the only future-proof way for now 🙁
• We don't have an ETA for fixing this as no contributor has been able to reproduce this bug yet. I don't have a laptop with NVIDIA Optimus graphics anymore.

[git2013vb]

* Try using `primusrun` instead of `optirun`. It generally performs better.

* Bumblebee is considered deprecated by now. NVIDIA's built-in PRIME support should be used instead, no latter how inconvenient it may be. It's the only future-proof way for now slightly_frowning_face

* We don't have an ETA for fixing this as no contributor has been able to reproduce this bug yet. I don't have a laptop with NVIDIA Optimus graphics anymore.

For what I know primusrun is for compatibility to use intel as if it were nvidia. I tried already. the problem is in the code. I use other programs with optrun and they work properly (aka blender to give an example or glxgears)

If you don't have a laptop that's fine I have it :). I can try to fix the problem. I will be in touch in chat. :)

Thanks

[git2013vb]

OK, after several bisects, I found the exactly section where the problem lie:

(base) vale@debianace:~/godotdev/godot$ git bisect bad
f725d9cb733e103c91d889777b78c5a646095658 is the first bad commit
commit f725d9cb733e103c91d889777b78c5a646095658
Author: PouleyKetchoupp <pouleyketchoup@gmail.com>
Date:   Fri Sep 25 18:16:39 2020 +0200

    Fix issues related to delay when processing events on Linux

    3.2 backport of PR #41910:
    Fix general keyboard input lag on X11 display server
    Fix delay to process clipboard content from Godot in other programs

 core/error_macros.h     |  27 ++++
 core/local_vector.h     | 246 +++++++++++++++++++++++++++++++++
 platform/x11/os_x11.cpp | 355 ++++++++++++++++++++++++++++++------------------
 platform/x11/os_x11.h   |  18 ++-
 4 files changed, 515 insertions(+), 131 deletions(-)
 create mode 100644 core/local_vector.h
(base) vale@debianace:~/godotdev/godot$ 

I'm not sure if I can fix it by myself.

Any hints?

[pouleyKetchoupp]

I'll have a look at the code next week to see if I can figure out how these changes can cause issues with resizing the window.

[git2013vb]

@pouleyKetchoupp Another info that is related. Maybe can help you in your investigation:

When I have godot opened, last beta for example, - in editor - I can't open any other programs using optirun. Thy don't give me any error . Seems like they put themself in pause. because if in the meantime I'll close godot they go ahead and start normally. While If I open the old godot, a version before your upgrade, I can open any other program that use optirun. here where blender will put itself in pause while godot is opened:

[258641.190838] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
[258641.190998] [INFO]Configured driver: nvidia
[258641.191150] [DEBUG]optirun version 3.2.1 starting...
[258641.191160] [DEBUG]Active configuration:
[258641.191164] [DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[258641.191167] [DEBUG] X display: :8
[258641.191169] [DEBUG] LD_LIBRARY_PATH: /usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/x86_64-linux-gnu:/usr/lib/i386-linux-gnu
[258641.191172] [DEBUG] Socket path: /var/run/bumblebee.socket
[258641.191176] [DEBUG] Accel/display bridge: auto
[258641.191181] [DEBUG] VGL Compression: proxy
[258641.191183] [DEBUG] VGLrun extra options: 
[258641.191190] [DEBUG] Primus LD Path: /usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus
[258641.191224] [DEBUG]Using auto-detected bridge virtualgl

Then if I close godot blender terminal close too. Then If I open blender it will open:

[258805.072943] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
[258805.073178] [INFO]Configured driver: nvidia
[258805.073364] [DEBUG]optirun version 3.2.1 starting...
[258805.073374] [DEBUG]Active configuration:
[258805.073378] [DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[258805.073395] [DEBUG] X display: :8
[258805.073398] [DEBUG] LD_LIBRARY_PATH: /usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/x86_64-linux-gnu:/usr/lib/i386-linux-gnu
[258805.073401] [DEBUG] Socket path: /var/run/bumblebee.socket
[258805.073406] [DEBUG] Accel/display bridge: auto
[258805.073410] [DEBUG] VGL Compression: proxy
[258805.073413] [DEBUG] VGLrun extra options: 
[258805.073415] [DEBUG] Primus LD Path: /usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus
[258805.073436] [DEBUG]Using auto-detected bridge virtualgl
[258805.793922] [INFO]Response: Yes. X is active.

[258805.793953] [INFO]Running application using virtualgl.
[258805.794273] [DEBUG]Process vglrun started, PID 303691.
Read prefs: /home/vale/.config/blender/2.93/config/userpref.blend
/home/vale/.config/blender/2.93/scripts/addons/archipack_20/archipack_py_deps_installer.py:33: RuntimeWarning: Use 'sys.executable' instead of 'binary_path_python'!
  PYPATH = bpy.app.binary_path_python
Archipack PRO 2.3.3 : ready

Hope is helpful

Thanks.

[git2013vb]

I'll have a look at the code next week to see if I can figure out how these changes can cause issues with resizing the window.

@Calinou , @pouleyKetchoupp Hi, Any news? As mentioned before my laptop use NVIDIA Optimus so I'm more than happy to test the fix when it is ready. Or if you don't have time just tell me how to fix it and I'm happy to do it :) Just don't keep me in the dark please ;) Thanks

[pouleyKetchoupp]

@git2013vb Sorry for the lack of update. I was able to reproduce the issue on my optimus config when using optirun, but no luck so far to fix it or work around it.

From what I've seen, the correct window size is set in the Vulkan renderer but the window still seems to be rendered with an incorrect size, so I'm still not sure what's happening. It looks like it might be a bug on the X server side, that somehow appears depending on the timing between requests.

I'll try to investigate more when I find some time, but as @Calinou mentioned, for the time being you'll probably have less problems using some alternatives for optimus.

[git2013vb]

@pouleyKetchoupp Thank you for your update. Did you tried to use opengl instead of vulkan? Just to check if its related to vulkan (I would exclude problems in linux side)

ps.:My only alternative is to use INTEL card :(

[pouleyKetchoupp]

Did you tried to use opengl instead of vulkan? Just to check if its related to vulkan (I would exclude problems in linux side)

Sorry, I actually meant openGL, I've reproduced the issue on 3.x. I confused myself by switching between branches with different renderers. But I'll actually try on 4.0 too when I have a chance, I'm not sure whether the issue is present with Vulkan.

[pouleyKetchoupp]

I've checked again today and can't find a rational cause for this issue. It looks like it might be a bug in the driver when using optirun that depends on some timing and didn't happen by chance before.

Maybe someone from @godotengine/rendering would know what could cause such an issue in GLES2/GLES3? The window size is updated correctly but it looks like in some cases the frame is still being rendered at the wrong size.

@git2013vb What I can propose for now (as long as other maintainers agree) is to add a project setting in 3.x that can be used to disable the event thread on Linux (it's used to get more reactive inputs so if you disable it you would just be back to what 3.2.3 was doing). Would that help you?

Then we can take more time figuring out if we need to solve the problem in 4.0.

[git2013vb]

@pouleyKetchoupp Yes, I think so. If the event tread is not mandatory to be able to use Godot I think its a good idea to be able to enable/disable from project settings Honesty I would like to fix it by myself. However I have difficult to understand Godot codebase. I guess I will need time to be able to do it.

[lawnjelly]

It does look like a problem with the order of things being called, this is fairly common with window resizing in my experience. Something like it is doing a redraw of the screen before it has had the opportunity to resize the elements, or an intermediate surface is one frame out of date (especially if this is GLES3 only? does it occur in GLES2?).

If could be that the window resize input (from the mouse?) is expecting to be received at a certain point in the main loop, and by making the input more efficient it's now turning up at the 'wrong' spot and causing this. One related option can be to defer the resize event (i.e. store the new size, but don't apply it until needed), although in this case I suspect it is the opposite problem, the physical window is getting resized before Godot is resizing. But I'm not sure, it could just be an intermediate surface, I don't know exactly how the editor is rendered.

Without seeing the exact behaviour it is difficult to guess, a video would be useful. Does it fix itself after a few frames after resize? Or is it an ongoing problem? These would be two different things. If it is an ongoing problem after resize, it is possible the editor has missed a resize input event, and thinks the window should be a different size?

Unlikely other possibility - this could also be related to any extensions we are using regarding the frame buffer and driver bugs. I've had this kind of thing happen before with some swap hint extensions.

[git2013vb]

does it occur in GLES2?

Yes , it does.

Or is it an ongoing problem?

this.
I made a short video: @pouleyKetchoupp @lawnjelly test.mp4.zip

[pouleyKetchoupp]

@lawnjelly Thanks for your comment! Note that the issue only occurs when running godot with optirun and hasn't been reproduced with other Optimus alternatives.

Without seeing the exact behaviour it is difficult to guess, a video would be useful. Does it fix itself after a few frames after resize? Or is it an ongoing problem? These would be two different things. If it is an ongoing problem after resize, it is possible the editor has missed a resize input event, and thinks the window should be a different size?

It is an ongoing problem, like the window's size always lags behind Godot's rendering size (or the other way around). But I've checked and it looks like all resize events are processed correctly, the size used in the GLES2/3 renderer is updated and redraw is triggered. That's why I was suspecting a bug on the x server side when optirun is used.

For now I'm going to add the option in 3.x to disable the event thread and I'll test in 4.0 to see if the problem happens with Vulkan as well.

[lawnjelly]

Yeah could well be a bug outside our code too. Another idea - try running it through a graphics debugger like API trace (https://github.com/apitrace/apitrace) etc on the hardware that causes the problem, capture a trace and replay it and see if you can work out what is going on.

[akien-mga]

Is this still reproducible in the latest 3.5 betas?

If you're able to run Godot 4.0 with Vulkan, can you see if it also has the same issue?

[git2013vb]

Yes, it is in 3.5 beta4. I cannot use Godot 4.0 yet.

[git2013vb]

I tried the 3.5 mono stable and it wont start.

I have this error:

(base) vale@debianace:~/Downloads/godot_mono/Godot_v3.5-stable_mono_x11_64$ optirun ./Godot_v3.5-stable_mono_x11.64 
Godot Engine v3.5.stable.mono.official.991bb6ac7 - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GT 650M/PCIe/SSE2
Async. shader compilation: OFF

Mono: Log file is: '/home/vale/.local/share/godot/mono/mono_logs/2022-08-08_08.09.38_1167055.log'
Project is missing: /home/vale/godot/tutorials/NestedProjects/project.godot
Project is missing: /home/vale/godot/tutorials/NestedProjects/common/project.godot
Editing project: /home/vale/godot/DesertEdgeSharp/client (::home::vale::godot::DesertEdgeSharp::client)
Godot Engine v3.5.stable.mono.official.991bb6ac7 - https://godotengine.org
XInput: Refreshing devices.
XInput: No touch devices found.
Custom libGL override detected. Skipping GPU detection
Using GLES3 video driver
OpenGL ES 3.0 Renderer: GeForce GT 650M/PCIe/SSE2
Async. shader compilation: OFF
OpenGL ES 2D Batching: ON
Batching Options:
    max_join_item_commands 16
    colored_vertex_format_threshold 0.25
    batch_buffer_size 16384
    light_scissor_area_threshold 1
    item_reordering_lookahead 4
    light_max_join_items 32
    single_rect_fallback False
    debug_flash False
    diagnose_frame False
(base) vale@debianace:~/Downloads/godot_mono/Godot_v3.5-stable_mono_x11_64$ XIO:  fatal IO error 2 (No such file or directory) on X server ":8"
[2022-08-08_08.09.38_1167055.log](https://github.com/godotengine/godot/files/9279200/2022-08-08_08.09.38_1167055.log)

      after 47 requests (47 known processed) with 0 events remaining.
(base) vale@debianace:~/Downloads/godot_mono/Godot_v3.5-stable_mono_x11_64$ 

This issue was not fixed? its tagged 3.5

Can you tell me when it will be fixed? In still not able to use Godot.

Thank you.

2022-08-08_08.09.38_1167055.log

[akien-mga]

Pretty much the same status as in https://github.com/godotengine/godot/issues/48091#issuecomment-912984799

Bumblebee is a big hack and no longer maintained since many years. It doesn't play nice with Godot but there's not much we can do without a deep dive into its hacks to understand why it fails, and no contributor seems particularly interested in doing so (which also requires an Optimus laptop using a distro which does not provide a better implementation of Reverse PRIME than the bumblebee hack).

[git2013vb]

Pretty much the same status as in #48091 (comment)

Bumblebee is a big hack and no longer maintained since many years. It doesn't play nice with Godot but there's not much we can do without a deep dive into its hacks to understand why it fails, and no contributor seems particularly interested in doing so (which also requires an Optimus laptop using a distro which does not provide a better implementation of Reverse PRIME than the bumblebee hack).

I don't know how other softaware manage to be able to work with it. Is not my field of expertise. What I know I can use regularly software like Blender without any hacks :)

Maybe is not so hard to fix as you might think?

If its a regression how is so hard to come back at how was before? After all effort in my side to pinout the exactly version where the regression is and after all my effort to help with debug and testing are you saying I will not be able to use Godot unless I have to buy another computer? Just for Godot only?

Because anything else in my current computer is working just fine e.g: (Blender, Inkscape, Gimp, Krita, Dota2, Bevy, Fyrox PlayOnLinux,... - using no hack at all)

Also the guy who did the changes related to this regression is still here in Godot team and seems he have already a solution . I think he need a "go" from you (you as project leader/responsible/person in charge) to be fixed. Don't tell me because nobody else have this problem (so far) it will not be fixed? That's will be interesting :)

Thanks.

[akien-mga]

Also the guy who did the changes related to this regression is still here in Godot team and seems he have already a solution . I think he need a "go" from you (you as project leader/responsible/person in charge) to be fixed.

pouleyKetchoupp is no longer actively contributing so someone else would have to pick it up.

Multiple comments here suggest using primusrun which is a much better bridge than the default one used by optirun. Did you ever try that?

[git2013vb]

Also the guy who did the changes related to this regression is still here in Godot team and seems he have already a solution . I think he need a "go" from you (you as project leader/responsible/person in charge) to be fixed.

pouleyKetchoupp is no longer actively contributing so someone else would have to pick it up.

It is from Jan/2022?:

https://downloads.tuxfamily.org/godotengine/3.5/rc8/Godot_v3.5-rc8_changelog_authors.txt
PouleyKetchoupp (13):
      Fix errors in mouse detection when removing collision object from tree
      Fix SoftBody memory corruption when using invalid mesh
      Fix SoftBody memory corruption when switching mesh at runtime
      Fix RigidBody collision update after changing collision layer/mask
      Add X11 events logging for debug purpose
      Expose intersect_point in 3D physics server
      Add support for motion in 2D intersect_shape function
      Fix errors in KinematicBody when floor is destroyed or removed
      Fix test_move reporting collision when touching another body
      Fix physics BVH pairing for teleported or fast moving objects
      Fix shape index in multiple physics queries with Bullet
      Handle test body motion with 0 margin
      Fixed ccd enabled by default on Bullet bodies

Multiple comments here suggest using primusrun which is a much better bridge than the default one used by optirun. Did you ever try that?

Yes , of course I tried. But with Godot it not work. Any other software I mentioned before they work. Any suggestions?