mirror of
https://github.com/mpv-player/mpv
synced 2025-02-07 15:41:55 +00:00
cc746c9508
...probably. The EGL backend had a strange problem: when recreating the window, EGL surface creation sometimes mysteriously failed. For example, keeping the "_" key down (cycles video by default) destroys and recreates the window in rapid succession, which will often enough show the "Could not create EGL surface!" message. This was puzzling because due to mpv's architecture, the X11 Window and even the X11 Display were fully destroyed, the thread on which they ran was destroyed, and then everything was recreated. There shouldn't have been any state that could make subsequent EGL initialization fail. It turns out mpv forgot to free EGLSurfaces in the x11 code. EGL is a pretty crazy API (full of thread local and global state with weird lifetime requirements), and for example it seems EGLDisplay cannot be explicitly released, but apparently implicitly dies when the native display is closed (at least EGL 1.5 claims eglTerminate() does _not_ invalidate the display, only certain objects linked to it). It appears that Mesa still referenced at least EGLSurface in some form, and either some pointer or some X11 ID was dangling, and when it randomly matched when eglCreateWindowSurface() was called, it failed. Fix this by calling eglTerminate(), which supposedly destroys (or rather unreferences) contexts and surfaces created from the display (but absurdly not the display itself). Now why can't you just destroy the display? If it's implicitly invalidated, why can't it just call eglTerminate() implicitly when this happens? Did Mesa do something wrong when they somehow didn't automatically remove the dangling object (so I could claim not to be responsible for the bug)? Who the fuck knows, and I'm too tired to figure this out (both because it's late, and because I'm tired of this EGL crap API). Still not sure if the code is correct now. I think EGL was designed to maximize implementation and API-use complications. How else could you possibly come up with something like the EGLDisplay life cycle? Or am I just making a fuss? Anyway, fuck EGL, fuck computers, fuck technology. Fixes: #7129 |
||
|---|---|---|
| .. | ||
| angle_dynamic.c | ||
| angle_dynamic.h | ||
| common.c | ||
| common.h | ||
| context_android.c | ||
| context_angle.c | ||
| context_cocoa.c | ||
| context_drm_egl.c | ||
| context_dxinterop.c | ||
| context_glx.c | ||
| context_rpi.c | ||
| context_wayland.c | ||
| context_win.c | ||
| context_x11egl.c | ||
| context.c | ||
| context.h | ||
| egl_helpers.c | ||
| egl_helpers.h | ||
| formats.c | ||
| formats.h | ||
| gl_headers.h | ||
| hwdec_d3d11egl.c | ||
| hwdec_drmprime_drm.c | ||
| hwdec_dxva2egl.c | ||
| hwdec_dxva2gldx.c | ||
| hwdec_ios.m | ||
| hwdec_osx.c | ||
| hwdec_rpi.c | ||
| hwdec_vdpau.c | ||
| libmpv_gl.c | ||
| oml_sync.c | ||
| oml_sync.h | ||
| ra_gl.c | ||
| ra_gl.h | ||
| utils.c | ||
| utils.h | ||