StringViews are great -- given that they are trivially destructible, the
compiler can now tell me that I have unused variables. If it wouldn't be
trivially destructible (like std::string), the destructor is treated as
if it has side-effects so the compiler won't complain.
We're going to eventually include this class in all Application classes
(need that in order to inherit a to-be-created Configuration class) and
the <string> and <vector> would be just too much. This change caused
magnum-gl-info.wasm (WebGL 2 build) to go down from 247 to 245 kB. Not
much, but that's I guess because there's still a lot other vectors of
strings elsewhere.
There's a lot more places to clean up, will do those in separate
commits. This change is the most atomic I could do, and it introduces a
breaking change to all APIs that returned a std::vector or a
std::string. Fortunately (or as I hope) those weren't used that much, so
it shouldn't cause build breakages for that many people.
Quite a lot of the optimization ideas is borrowed from the new Vk
library -- such as "interning" the driver workaround strings to avoid
allocating their copies.
This was done silently until now and I think such platform-specific code
should be always exposed as a disableable workaround. Moreover, I need a
similar thing for ANGLE, so this comes handy.
This was my bug, as requesting a forward-compatible context without
saying *what* version it should be forward compatible to makes no sense.
A followup to 73baab69ce.
There's a new firefox-fake-disjoint-timer-query-webgl2 workaround and a
half-page of text listing various caveats and issues you might run into.
Also exposing them in the OpenGLTester (although quite shitty at this
point).
This one explicitly loads GL 1.0 and 1.0 function pointers on EGL
contexts on NVidia drivers (Linux headless boxes), because somehow the
usual statically linked functions don't behave correctly.
There's much more to work around / fix, but this is a start. First we
need to create the context with a pbuffer, otherwise eglMakeCurrent()
crashes deep inside. Second, it doesn't treat EGL_CONTEXT_FLAGS_KHR as a
bitfield, so it blows up when encountering a combination of zero flags.
In that case we're simply not sending the flags there. This would also
blow up when there's more than one flag passed, but there's just one
flag for debug context at the moment, so shouldn't be a problem.