Panels don't draw when using VSCode's debug mode under Windows (other OS's work fine, as does non-debug mode)

[ddkwork]

On windows, the demo in goland debug mode renders the layout but doesn't show up on the main window. How to reproduce: Goland opens unison demo, clicks debug, sees no content in the panel inside the window, the After careful troubleshooting, the following commit id that causes this bug:

42c26e1249b14c404a071392a2a6a51525d7b4d8 ok ，last working version

d845b56964c1c227fde3bd819d5656818d43645a bug start

[richardwilkes]

I almost never use Windows, so haven't seen this when debugging. When I get some spare time, I'll take a look, though. Given my current workload, that may not be soon.

[richardwilkes]

I've now had a chance to verify that debugging on Windows with any version beyond 42c26e1 causes all panels to be blank. Running without the debugger works fine, as does using macOS or Linux, whether in debug mode or not.

Since I don't use Windows for debugging, this doesn't affect me. I'd like to find a solution, but nothing obvious in that commit was changed that should affect rendering like this and my time is limited, so this is likely to remain open until someone else who really needs to be able to debug on Windows can spend the time to determine what the actual issue is.

[ddkwork]

I spent a few days checking the commits related to root panel and Window draw but no useful error messages appeared, I thought it could only be related to the compilation parameters of skia, unfortunately it's quite difficult to access github in China, and it's a bit overwhelming to clone a few gb's worth of skia repositories.

[richardwilkes]

My first thought was also that skia had changed in some manner... however, there was no update of the skia library between the version that works and the one that doesn't.

[ddkwork]

Based on the experience of using it these days, it is very likely that the parent of a panel is set wrongly. Because I had a similar problem when I was designing this debug interface using unison. https://github.com/HyperDbg/gui What's interesting is that you can manipulate the panel even though you don't see it being rendered, assuming you know where each widget is located.

[richardwilkes]

Not likely, if you can actually interact with it despite it not drawing. The layout would not place things in the correct place if the parent was incorrect, nor would any events reach it.

That also doesn't explain why it works fine without the debugger attached.

[ddkwork]

👍👍👍我想你是对的

---Original--- From: "Richard @.> Date: Fri, Jun 28, 2024 23:18 PM To: @.>; Cc: @.**@.>; Subject: Re: [richardwilkes/unison] Panels don't draw when using VSCode'sdebug mode under Windows (other OS's work fine, as does non-debug mode) (Issue#51)

Not likely, if you can actually interact with it despite it not drawing. The layout would not place things in the correct place if the parent was incorrect, nor would any events reach it.

That also doesn't explain why it works fine without the debugger attached.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ddkwork]

This catches some errors, but nothing to go on, do you have any instructions? thx

    wnd.MouseEnterCallback = func(where unison.Point, mod unison.Modifiers) bool {
        wnd.SetFocus(wnd.Content())
        wnd.Focus()
        //wnd.FocusNext()
        wnd.SetContent(unison.NewButton())
        wnd.Wnd().SwapBuffers()
        wnd.Wnd().Show()
        return true
    }

INF | 2024-07-15 | 02:23:00.797 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:00.985 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:01.091 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:01.506 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:01.664 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:01.881 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:01.956 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:02.030 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:02.047 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:02.050 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:03.434 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:03.707 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:03.756 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:03.838 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:04.146 | PlatformError: WGL: Failed to make context current: The handle is invalid. 
INF | 2024-07-15 | 02:23:04.160 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 
INF | 2024-07-15 | 02:23:04.264 | PlatformError: WGL: Failed to make context current: The requested transformation operation is not supported. 

[richardwilkes]

This is an invalid use of SwapBuffers. You will get random results.

[ddkwork]

oh

---Original--- From: "Richard @.> Date: Mon, Jul 15, 2024 02:42 AM To: @.>; Cc: @.**@.>; Subject: Re: [richardwilkes/unison] Panels don't draw when using VSCode'sdebug mode under Windows (other OS's work fine, as does non-debug mode) (Issue#51)

This is an invalid use of SwapBuffers. You will get random results.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[ddkwork]

    wnd.MouseEnterCallback = func(where unison.Point, mod unison.Modifiers) bool {
        runtime.LockOSThread()
        //wnd.SetFocus(wnd.Content())
        //wnd.Focus()
        ////wnd.FocusNext()
        //wnd.Wnd().Focus()
        wnd.SetContent(unison.NewButton())
        //wnd.Wnd().SwapBuffers()
        //wnd.Wnd().Show()
        return true
    }

No, an error can occur without a swap buffer. Can this be an entry point?

[richardwilkes]

The use of LockOSThread is also not appropriate here and will cause problems.

Why do you think mouse enter events are relevant?

[ddkwork]

Locking threads commented out can also be captured, as there is no better tangent event to immediately trigger setting the context of the window

[richardwilkes]

You're still not making any sense. What are you trying to accomplish? The OpenGL context is set appropriately at draw time and that's the only time it needs to be dealt with. Unless you've gone out of your way to break the way drawing is done, this is all automatic in unison.

[ddkwork]

[richardwilkes]

Yes, I get that there is some interaction on Windows with the debugger that is causing the OpenGL canvas to not draw -- that's the subject of this issue. However, mouse events are not related to this in any way that I can determine, so why are you messing with that aspect?

[ddkwork]

Didn't I explain that before? Other than that there is no immediate way to trigger the bug, unless you have one, please tell me how to force the bug to be triggered

[richardwilkes]

For me -- on Windows only -- if I run the demo with the debugger, it just never draws anything in the window. That's the bug. No mucking about with the mouse events matters. Why this happens, I don't know. It appears that the Windows version of the debugger is somehow messing around with the OpenGL context, which it should not be doing -- and doesn't on all other platforms.

Anyway, this is not a problem for me, as I almost never use Windows for development, as it is an extremely poor platform for such activities. I only ever use it when debugging a problem, and I can get by with printf-style debugging in those cases where I absolutely must use Windows to debug a problem. Because of this, I've not invested much time or energy into trying to determine why Windows is doing the wrong thing.

[ddkwork]

That's okay, I'll try to find some time to see if I can figure it out. Since I'm only using Windows at the moment, Linux is only used occasionally. Interestingly, the screenshot just now is the same behavior in debug mode for that commit id I specified, and it didn't throw an error.

Maybe I should just wrap the widget back to the old version and upgrade the new version when it's resolved. Because this kind of problem is unlikely to be solved anytime soon.

If you are too busy, you can close this issue.

[richardwilkes]

I'll leave it open, as it is a real issue.

[ddkwork]

After debugging glfw and finding that the corrupted context or handle comes from the api parameter before gl handles the drawing and it comes from skia, it looks like the bug comes from skia and I need to test the main or m128 branch of skia

[ddkwork]

Hi, after testing the main branch skia still has this problem, then m128 should be the same, but the old version I guess is no longer compatible with the c api, can you give me a version between m118-m127 that probably might work? If switching multiple versions doesn't work, then you can narrow down the troubleshooting. thanks!!!

[richardwilkes]

As I noted at the very start of this issue, there was no skia change between a working version and a non-working version, so it is unlikely to be in that area. It might be in the version of glfw that was used. I've not checked that.

[ddkwork]

I solved the problem by downgrading the unison version, so close this topic

[ddkwork]

Looks like a good start, it uses vulkan to implement a unified backend, I'll try to copy this package to replace glfw in order to support the android backend engine

https://github.com/cogentcore/core/tree/main/system

[richardwilkes]

Unfortunately, the last time I looked at vulkan (admittedly, a couple of years ago), it had a fairly large number of problems and did not work well on all platforms.