Window resizing causes flickering and strange results on Windows #21

New Issue

bvisness · 2023-07-22T22:37:13Z

bvisness commented

2023-07-22 22:37:13 +00:00

See video: https://cdn.discordapp.com/attachments/1126271320364167299/1131356073949921310/20230719_174430.mp4

I am away from my PC now but can get the specs later if necessary...

See video: https://cdn.discordapp.com/attachments/1126271320364167299/1131356073949921310/20230719_174430.mp4 I am away from my PC now but can get the specs later if necessary...

bvisness added this to the Jam MVP milestone 2023-07-23 17:38:08 +00:00

MartinFouilleul commented

2023-07-25 09:51:44 +00:00

The reason for the view popping out of the window are all very silly:

Windows can't do transparent child windows.
So we have to use top-level windows that we setup on top of the main window
But then these aren't clipped, so we have to clip the desired surface frame to the main window, and set the real frame of the surface's transparent window to that clipped rect.
With all that I got confused and messed up the repositionning code.
When rendering, we also have to ensure that the renderer's intermediate textures and tile buffers are actually resized to the correct surface size.

I can fix the buffer resizing and the window repositionning stuff, but I have bumped onto another problem with this hack:

Clipping the surfaces to the main window manually messes up with functions like glViewport() that are set wrt the surface's window, which is now of different dimensions/positions than the user-specified surface frame.

Besides, we're not really using the ability to set the surface's frame! I did use it in the jam prototype to restrict the area where the wasm guest can draw, ie to separate the "chrome" from the app's client area. There's not really a chrome in this version (there might be in the launcher version).

So, maybe for now I can just entirely remove the ability to set surfaces' frames, and always make them the size of the window's content rect (and thus auto-resize).

There would be no need for changes for the macos impl. besides removing the frame functions and turning on autoresizeMask of sublayers.
We can keep our top-level window hack on windows but don't have to clip the surface's frames anymore, which simplifies the positionning code and doesn't mess with glViewport().

Later if we need to separate the orca "chrome" from the app's area, we could always come up with a way to expose true child windows (that don't need to be transparent), and have the app's surface be created for a child window instead of the main window.

We could also try to avoid the whole hack of top-level transparent windows and instead do the surface compositing ourselves, but this requires some level of interop between the different surfaces (e.g. being able to write to a texture using a GLES backend and read from it using a desktop GL or D3D backend, without doing a GPU<->CPU roundtrip).

The reason for the view popping out of the window are all very silly: - Windows can't do transparent child windows. - So we have to use top-level windows that we setup on top of the main window - But then these aren't clipped, so we have to clip the desired surface frame to the main window, and set the real frame of the surface's transparent window to that clipped rect. - With all that I got confused and messed up the repositionning code. - When rendering, we also have to ensure that the renderer's intermediate textures and tile buffers are actually resized to the correct surface size. I can fix the buffer resizing and the window repositionning stuff, but I have bumped onto another problem with this hack: - Clipping the surfaces to the main window manually messes up with functions like `glViewport()` that are set wrt the surface's _window_, which is now of different dimensions/positions than the user-specified surface _frame_. Besides, we're not _really_ using the ability to set the surface's frame! I did use it in the jam prototype to restrict the area where the wasm guest can draw, ie to separate the "chrome" from the app's client area. There's not really a chrome in this version (there might be in the launcher version). **So, maybe for now I can just entirely remove the ability to set surfaces' frames, and always make them the size of the window's content rect (and thus auto-resize).** - There would be no need for changes for the macos impl. besides removing the frame functions and turning on `autoresizeMask` of sublayers. - We can keep our top-level window hack on windows but don't have to clip the surface's frames anymore, which simplifies the positionning code and doesn't mess with `glViewport()`. Later if we need to separate the orca "chrome" from the app's area, we could always come up with a way to expose _true_ child windows (that don't need to be transparent), and have the app's surface be created for a child window instead of the main window. We could also try to avoid the whole hack of top-level transparent windows and instead do the surface compositing ourselves, but this requires some level of interop between the different surfaces (e.g. being able to write to a texture using a GLES backend and read from it using a desktop GL or D3D backend, without doing a GPU<->CPU roundtrip).

MartinFouilleul self-assigned this 2023-07-25 09:55:15 +00:00

MartinFouilleul referenced this issue

2023-07-25 10:11:25 +00:00

Port vector graphics renderer to D3D #23

MartinFouilleul commented

2023-07-26 15:57:53 +00:00

Fixed in 23f0d75e20. As discussed above, surfaces are now autoresized to the window contents dimensions (meaning we can't manually set their frame inside the window). This simplifies the handling of surfaces on Windows a bit.
There's still some caveats with resizing though (see #24), but at least the flickering and jumping around should be fixed.

Fixed in 23f0d75e20. As discussed above, surfaces are now autoresized to the window contents dimensions (meaning we can't manually set their frame inside the window). This simplifies the handling of surfaces on Windows a bit. There's still some caveats with resizing though (see #24), but at least the flickering and jumping around should be fixed.

MartinFouilleul closed this issue

2023-07-26 15:57:53 +00:00

Sign in to join this conversation.