./src/unix/glegl.cpp(560): assert ""Assert failure""

[Frank Cox]

When I try to load dcpomatic or the player program I get these messages in succession:

./src/unix/glegl.cpp(560): assert ""Assert failure"" failed in InitConfig(): Unable to get EGL Display
./src/unix/glegl.cpp(369): assert ""Assert failure"" failed in InitVisual(): Failed to get an EGLConfig for the requested attributes.
./src/gtk/window.cpp(3779): assert ""m_widget"" failed in DoSetSize(): invalid window
./src/gtk/window.cpp(3779): assert ""m_widget"" failed in DoSetSize(): invalid window
./src/gtk/window.cpp(3779): assert ""m_widget"" failed in DoSetSize(): invalid window

Then the program disappears without ever having actually started.

The same series of errors with both programs. They both worked this morning.

I just deleted the directory ~/.config/dcpomatic2 and everything appears to work again.

I'm using the appimages.

[carl]

I guess you tested the "OpenGL" option but didn't restart after selecting it... (it only takes effect when you restart).

And something is maybe broken with the OpenGL support with the AppImages - I'll have a try, thanks!

[Frank Cox]

I think that's what I did, indeed.

Thanks, Carl.

[Carsten]

Frank - I guess on your system, you can omit the OpenGL option anyway - I think it only is necessary on Macs because of specific display performance issues. The config files are human readable - if e.g. your apps won't start up because of a bad opengl setting, you can edit that specific setting in a text editor instead of dumping the whole config. I never actually dump config files in cases like this, I just rename them so I can restore them if necessary. Admittedly, you probably haven't set too many personal prefs so far, so dumping wouldn't hurt much for the time being.

[carl]

I see the crash here too: https://dcpomatic.com/bugs/view.php?id=2926

Over on film-tech I suggested that Frank try it as an experiment to see if it helped his system play 4K content.

[Carsten]

I have no personal experience with the Linux video display performance - but I assume 4k J2K in DCP-o-matic player is still too complex even for very fast machines. The Macs seem to have a very specific issue here. VLC does not have that issue on Macs, wondering how VLC addresses non-hardware-accelerated video display so much better than DCP-o-matic.

[carl]

I don't know the VLC code but I'd be surprised if they didn't use something "hardware accelerated", perhaps Metal on macOS.

[Kewl]

I don't know the VLC code but I'd be surprised if they didn't use something "hardware accelerated", perhaps Metal on macOS.

VLC (and IINA, another good video player, based on mpv) have optional hardware accelerated decoding, but, AFAIK, it not "ON" by default.

[carl]

I was thinking more about the blit of the image to the screen - the "safe" mode of DCP-o-matic does that in quite an inefficient way (apparently more inefficient on macOS than other platforms).

[Carsten]

Yes, VLC does support hardware acceleration, but it also works without, at least if content and resolution is not too demanding.