Profiling shows that a considerable amount of time is spent in
glBindBuffer and glBufferSubData when the damage rects are updated.
Since the amount of data here is quite small it's far faster to check if
it's different then to just blindly overwrite the buffer on each call.
Profiled on an Intel CPU with UHD P630 Graphics using magic-trace
The desktop doesn't need its own sampler, there is already an identically
configured one in the `desktop->texture`.
For some reason, using the texture sampler fixes a black screen issue
with my GTX 660 using the 470.86 driver. Maybe hitting some limit
for how many samplers can be allocated?
On my machine (Intel UHD Graphics 770), texture processing occasionally
(about 5% of the time) takes more than 20ms (the highest I have seen is
around 32ms) when the host resolution is 2560x1440. This results in the
frame being discarded and the client displays a stale image. Increase the
timeout to 40ms.
This allows the client to work when the OpenGL implementation fails if
EGL_RENDER_BUFFER is passed, printing a warning. This should fix issues
with Nvidia proprietary drivers on Wayland.
NVIDIA still do not implement a complete/working DMABUF implementation
yet advertise support. Best to tell the public to complain to NVIDIA
instead of assuming it's a LG bug or an issue with their system.
filters are now not run if `egl_filterSetup` returns false, as such we
do not need additional `enable` checks in `prepare` or `run` and we can
bypass the filters even earlier if they are not enabled reducing load.
Since this->prepared will never be set to true unless the filter is
enabled, this results in the framebuffer setup being done every frame
for no reason, causing a lot of texture reallocations.
This commit adds check for the extensions that we need and then calls
the functions indirectly through gl_dynprocs.
This should improve compatibility with older versions of OpenGL, as we
now fallback to the ARB extensions if possible, and in the case of
glGenerateMipmap, we can handle the function not existing at all.