Not compliant to EGL spec

[Crisspl]

From EGL spec 1.5, paragraph 3.12:

Resources explicitly allocated by calls to EGL, such as contexts, surfaces, and configuration lists, are not affected by eglReleaseThread. Such resources belong not to the thread, but to the EGL implementation as a whole.

In this implementation, lists of contexts, surfaces and even displays are per-thread state. Just a note for future users. Please correct me if I'm wrong or at a time when something changes in that matter.

I'm doing some additions and/or corrections on my fork.

[McNopper]

If I have time, I can have a look at it. But if you fix it, please make a pull request.

[devshgraphicsprogramming]

If I have time, I can have a look at it. But if you fix it, please make a pull request.

he's fixed an astronomical amount of things ;)

[Crisspl]

Fixed in newest commit (https://github.com/Crisspl/EGL/commit/35f0fe73365bf2401aa060a7dc8ee3d2825436e6), however I needed C++11/14 for this, so EGL on my fork is C++ with C API now. You might want to have a look at previous commits as well. Sorry for this enormous diff, I don't really know what happened... (tested on Windows only)

[McNopper]

Thx a lot. Anyone tried out the Linux code path?

[devshgraphicsprogramming]

Thx a lot. Anyone tried out the Linux code path?

we will eventually, when we start running our engine off this on Linux

[McNopper]

Still relevant? https://github.com/McNopper/EGL/commit/f20cdac3745a0d45ce8a8358ea40389278ae91e5

[Crisspl]

Still relevant? f20cdac

I think i dont understand the question

[McNopper]

This is the commit, where a lot of changes happened. After this commit, is this issue still there?

[devshgraphicsprogramming]

The lists are mutexed and global now, not thread local.

The Linux path has been tested, except for Wayland.

[UX3D-nopper]

Okay, so let's keep it open.