-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gui duplicated when not full screen (regression in 3.2.4 beta 1) [Linux, Optimus] #48091
Comments
Can't reproduce on Manjaro, I guess this is something in your gfx card drivers? |
@git2013vb Which graphics card model and driver are you using? |
Its a nvidia card if I don't use optirun it work, but optirun allow me to run it in my nvidia card this issue is related to #47719 |
Hi, I think this too is a regression. btw Using 3.4 beta2 still I have the problem. |
@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.) |
I checked, It starts since 3.2.4 beta1 (https://downloads.tuxfamily.org/godotengine/3.2.4/beta1/mono/) |
Thanks, that helps narrow it down! Relevant changes between 3.2.3-stable and 3.2.4 beta 1 (2e073ec) for
I'm thinking either window click-through or event processing fixes may be related? @pouleyKetchoupp @bruvzg |
I will add an error' screenshot. and the log file mentioned in the error: |
v3.3.3.stable.mono.official [b973f99] affected too. |
using v3.4.beta4.mono.official [6a058cb] 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. :) |
|
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 |
OK, after several bisects, I found the exactly section where the problem lie:
I'm not sure if I can fix it by myself. Any hints? |
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. |
@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.
Then if I close godot blender terminal close too. Then If I open blender it will open:
Hope is helpful Thanks. |
@Calinou , @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. |
@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 :( |
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. |
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 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. |
@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 |
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. |
Yes , it does.
this. |
@lawnjelly Thanks for your comment! Note that the issue only occurs when running godot with
It is an ongoing problem, like the window's size always lags behind Godot's rendering size (or the other way around). 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. |
Yeah could well be a bug outside our code too. Another idea - try running it through a graphics debugger like |
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? |
Yes, it is in 3.5 beta4. |
I tried the 3.5 mono stable and it wont start. I have this error:
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. |
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 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. Thanks. |
pouleyKetchoupp is no longer actively contributing so someone else would have to pick it up. Multiple comments here suggest using |
It is from Jan/2022?:
Yes , of course I tried. But with Godot it not work. Any other software I mentioned before they work. |
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
The text was updated successfully, but these errors were encountered: