Weird sizing problem

[Mark Sibly]

Hi,

I'm having a weird problem with a resizable window.

My render code is basically just:

MakeContextCurrent();

glViewport( window size );

RenderEverything();

SwapBuffers();

However, when the window is being resized, there seems to be a one frame 'lag' where glViewport doesn't seem to be working properly - it looks like it's 'stuck' at the last viewport even though the window has a new size.

I can fix it by adding another SwapBuffers() just before the glViewport(), so my guess is perhaps the front/back buffers have independent viewports and they are getting out of sync somehow?

Even with the fix kludge, there is still some noticeable 'glitching' where the viewport isn't 'quite right', but it's minor and possibly DWM related? Without the fix, the viewport is always wrong until the next render when it catches up.

I am using SDL but it's all working fine on macos, linux.

Bye,

Mark

[Geoff Lang]

ANGLE's D3D backends currently only check for window resizes on the SwapBuffers call.  If we wanted more up to date size information, we would need to do a message loop on another thread in ANGLE which isn't very feasible.  You may get better results if you change when your application does it's message processing relative to the SwapBuffers call but this may impose delay in other ways.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Corentin Wallez]

How about doing this in the eglWaitClient call?

[Mark Sibly]

> ANGLE's D3D backends currently only check for window resizes on the SwapBuffers call

Thanks for that, explains everything! And no, please don't add anyhing crazy like another thread monitoring resizes...

I've managed to kludge around the various issues for now by:

* Moving the checkForOutOfDateSwap call to the top of SurafceD3D::swapRect and returning without swapping if swapchain was out of date.

* Commenting out the swapRect call in SwapChain11::resetOffscreenColorBuffer.

I still need to check for window size changes myself and do a dummy 'Swapbuffers' if window size has changed, but with the above changes I now get rock solid resize behavior.

Not sure if SwapBuffers doing NOP in the case of a window size change should be the default behaviour, but as far as I can work out the viewport (at least) will always be wrong for the first redraw after a window resize. Wont matter in most GL apps that just render constantly, but mine is event driven so it was much more noticeable that something was up.

Incidentally, what's the correct protocol for replying to a newsgroup message? I've just used 'reply to all', is this ok?

Bye,
Mark

[John Bauman]

In chrome we use PostSubBuffer(0, 0, 0, 0); to force ANGLE to check whether the swapchain needs to be resized. You can also use the EGL_ANGLE_window_fixed_size extension and recreate the swapchain at the new size when you detect a resize.

You might also try modifying ANGLE to use DXGI_SCALING_NONE instead of DXGI_SCALING_STRETCH when creating swapchains. That doesn't work on every system (I think you need Win7 platform update 1 and maybe a flip sequential swapchain) but it can help prevent stretching if the backbuffer size doesn't match the window size.

[James Ross-Gowan]

I'm having this issue as well. I just raised it on the ANGLE bug tracker (before I noticed this thread): http://anglebug.com/1438

In chrome we use PostSubBuffer(0, 0, 0, 0); to force ANGLE to check whether the swapchain needs to be resized.

We considered doing this to solve the problem in mpv, but it won't work in all cases, right? Only when DXGI 1.2 is available (and EGL_NV_post_sub_buffer is exposed.) It would be nice if there was an explicit way to resize the swapchain that worked in all cases.

[Geoff Lang]

What about Corentin's suggestion?  If we added a resize check to eglWaitClient it could then call it after resize events and ANGLE would have up-to-date size info without extensions.

--

[Geoff Lang]

it could then be called*

[James Ross-Gowan]

What about Corentin's suggestion?  If we added a resize check to eglWaitClient it could then call it after resize events and ANGLE would have up-to-date size info without extensions.

We could switch to using eglWaitClient if ANGLE implements that feature. (We have started using the eglPostSubBuffer(0, 0, 0, 0) trick, so changing that call to eglWaitClient() would be easy.) I wonder if it's an ideal solution though. I'm not an expert with EGL APIs, but it seems a bit weird to me that eglWaitClient would have side effects wrt. the size of the backbuffer. As I understand, eglWaitClient() is a noop in ANGLE/D3D, so it won't have any other side effects, but it might not be obvious to the API user that it is supposed to be used for this purpose.

Would it make sense for ANGLE to check the window size as lazily as possible, right before the rendertarget for the backbuffer is bound? That should ensure the correct backbuffer size is used for rendering, without accidentally resizing the backbuffers while the program is using them, and as a bonus, it would require any extra API functions.

On the other hand, I still like the idea of having a function to explicitly resize the swapchain. mpv has separate threads for windowing and video rendering, so it's possible that the video rendering thread won't have the latest window size when a frame is rendered while the window is being resized by the user. If the video rendering thread could resize the swapchain to what it thought was the current window size, that might make window resizing smoother.

[Corentin Wallez]

eglWaitClient is a direct copy of glXWaitClient that tells the GL driver to synchronize its internal state with the X server. In particular if the window size has changed, this will make sure the backbuffers are resized. It is crucial to use eglWaitClient in X11 so that backbuffers are resized just after a swapbuffers: resizing clobbers the backbuffers and without eglWaitClient Chromium flickers when resizing.

The situation on Windows is similar (apart from the child-window trick used by Chromium on X11): you want to tell the GL driver "please update your state with the window system right now" which is the eglWaitClient semantic. If you want to take a shot at implementing this, you just need to fill in the blank in DisplayD3D.

As for your window / video thread problem, you could have a child window nested in your main window, that gets resized to the size of the video frame. That's how Chromium handles resizing on Linux (code).

--

[James Ross-Gowan]

I guess if it works that way in X11/EGL, that's a pretty good precedent. It still seems strange to me, but it won't cause a problem for us in mpv and it should allow us to fix our resizing issues on DXGI 1.1 and below.

glXWaitClient

Wait, do you mean glXWaitGL or glXWaitX? We don't currently use either of these in mpv on X11, but I have noticed graphical glitches after resizing there as well, so we could try these out.

[Corentin Wallez]

Yep I meant glXWaitX but to completely fix your resizing problems on X11 you will probably have to use a child window too.

--

[Geoff Lang]

FYI, this is now landed in ANGLE.

[James Ross-Gowan]

FYI, this is now landed in ANGLE.

Great. Thanks for this change (and thanks Corentin for the X11 advice.)