Visual Bug With AutoCompletion #77582
Comments
|
Have you seen this behaviour on any earlier versions of Godot? I.e. is it new in 3.6 beta 2? I've not yet been able to reproduce but knowing when it started might help pinpoint the cause. The only significant rendering change off the top of my head in 3.6 beta 2 is MultiRect, which you can switch off by going to Also knowing your GPU / processor could be useful as this kind of thing is sometimes just down to graphics drivers. |
|
Only appear to me on 3.6 beta 2 i was using beta 1 never encounter this visual bug |
|
I did test disabled project_settings/rendering/batching/options/use_multirect still having this issue |
|
Ah, the GPU seems from 2008, so that is more suggestive of a driver / GPU bug, although why it should occur in beta 2 and not beta 1 I'm not sure. I've been looking through the commits but nothing obvious springs up. Kind of things we often try are getting you to make a recording with e.g. APITRACE or RenderDoc. This can sometimes suggest when something is likely to be a driver bug, as it records the OpenGL calls and we can examine the state, and see if it reproduces with the same API calls on different hardware. Also if you are able to go through the commits manually to bisect where the problem first occurs this can help pinpoint: You can often do this by downloading the artifacts from github from the PR pages (look for the green ticks on the CI builds) rather than building the engine yourself. For some reason this doesn't seem to be in the docs. Other option is just to be patient and see if anyone else reports the problem, often times this helps narrow it down, and if no one else does have the problem, it can be a GPU / driver issue |
|
I also get the issue for 3.6B2 (but not for 3.6B1) on two Intel NUC boxes, a Linux box (NUC7) and a Windows10 box (NUC6). Both have integrated Intel GPUs. The NUC7 was manufactured in early 2018. I reproduced the issue on both devices. For 3.6B2 there was obvious bleed-through. For 3.6B1, the autocomplete text background was opaque with no bleed-through. To test, I created a project each for 3.6B1 and 3.6B2 with a single script to test autocomplete against this visual glitch. I put them in separate folders so that each was pristine. I also deleted the editor_settings-3.tres file in each to force it to regenerate to default in both cases -- both regenerated files are identical. 3.6B1 - solid autocomplete background 3.6B2 - transparent background UPDATE: I can confirm the issue with 3.6B2 also happens on my gaming laptop, a Dell G15 5515 with Windows 10 and NVIDIA GeForce RTX 3060 6GB. |
|
I'll try and have another look at this if it is occurring on several systems, it makes it more difficult not being able to reproduce locally. Ideally we'd bisect it to the PR that introduced it (could well be one of mine 😁 ). EDIT: Ah correction, it is actually reproducing on my new PC! 👍 That should make it far easier to track down and fix. It doesn't appear to be the canvas layer ordering, I'll bisect tommorrow as it's bedtime. UPDATE: I have bisected and as suspected it is a regression from my MultiRect PR #68960 . It was down to changes to |
|
Here's the git bisect.
This looks wrong. I think I goofed (my first time bisecting) and will have to redo. Obviously any changes to OBJ importer file will not affect the editor. I think my misstep was using --depth 100 on the assumption that there were only around 50 commits between Beta 1 and Beta 2. |
|
Ah thanks! I've actually already bisected (manually) earlier and fixed it with the above PR, although it has to be reviewed and merged yet. I've never actually used the |
|
Good to hear it's fixed, but alarming that git bisect (in my case) wasn't even in the ballpark. I repeated the process from scratch without the --depth 100 when pulling the 3.x branch, and it followed the exact same sequence, so I no longer think I erred in how I carried out the bisect. At least I learned the way to do it. I'll take more opportunities to use it and decide if it's me |
|
Alright, just to put this bisect issue to bed, here's what I learned after my first try. You have to keep running bisects until your 'good' and 'bad' bisects meet up. I thought a single bisect job would eventually arrive at this state, where the good and bad commits are identified side by side, but that was not the case when I performed my bisect earlier in this thread. The good and bad-marked commits were still far apart. So I started a new bisect using the original 'good' commit but this time using the newly identified 'bad' commit value (ab8792c). After the second round of bisecting completed, I knew we had arrived at the actual bug commit, seeing the two bisects side by side:
|
|
Fixed by #79498. |
Godot version
3.6 Beta 2
System information
Linux: Xubuntu 20.04
Render Drive: GLES2
Processor : AMD Athlon(tm) Dual Core Processor 4450B
Integrated video card: AMD RS780C [Radeon 3100]
Issue description
When type some code times auto completion pass front the code
Steps to reproduce
Just type some code and can be appear some times
Minimal reproduction project
Just type some code and can be appear some times pass front
The text was updated successfully, but these errors were encountered: