+1 for your analysis! > One of the biggest issue of OpenGL is related with vsync, which is an > operation that can block all of the Pharo processes.
It does indeed, but is one way to sync with display rate (until we get threaded FFI of course then a thread can handle the wait). Currently we have to way to know the ideal time to start redraw, so as to minimise the delay between processing an event and displaying its feedback. Standard way is redraw with fixed independent frequency, which incurs an average feedback delay of (display period+redraw period)/2, and a waste of processing time if faster than display rate. VSync in video games has a bad press because people redraw right after it returns: _ Process events _ Draw scene _ Swap buffers <- pauses until scene is displayed _ Loop back That gives a worse feedback delay, but we could to pause a bit before processing stuff: _ Delay(display period - last redraw duration - redraw jitter) _ Process events _ Draw scene _ Swap buffers _ Loop back I find it very hard to find good info on VSync, and low latency event handling on PC in general, so please don't pan this idea too hard, this is just for experiment fun :) > A far worse problem with OpenGL is that the current OpenGL context is a > thread local variable, which do not interact at all with Pharo processes. > This is the reason of why I added the OSWindowRenderThread class for > serializing OSWindow and OpenGL animations. SDL2 renderers are usually > implemented using OpenGL. They are two correct solution for this problem: > - Having a VM that maps each Pharo Process into an operating system thread, > - Not using OpenGL at all. > > The others low level graphics API (Vulkan, Direct 3D and Metal) do not rely > on a global thread local storage variable. These APIs are object oriented, > so handles are passed in each API call. Yes, this is a major flaw in OpenGL. A GL context is global to all Pharo processes, meaning one Process could draw in an other Process area if preempted at the wrong moment. But a simple way to circumvent this is giving all display Processes (using OpenGL) the same priority. > Anyway, implementing a Athens backend from scratch is a really hard problem. Agreed. The difficulty with a hardware backend for Athens is it comes from software world. Some primitives are a nightmare to accelerate, resulting in usually incomplete hardware backends (https://developer.android.com/guide/topics/graphics/hardware-accel.html#unsupported). This is annoying for users because some primitives may turn off acceleration entirely, and force you to dig into the internal GL mud. To me the use of hardware drawing is either explicit or none. If appended to Athens it should be very clear what goes to the GPU and what not.
