Fix missing optimized shaders on OpenHarmony

[jschwe]

We use GLES on OpenHarmony, so the shaders should be optimizied accordingly. Cargo guarantees that the CARG_CFG variables are set. Using expect instead of matching improves the readability.

---

This re-applies 8468e81, which was lost when updating from 0.65 to 0.66.

[jschwe]

In terms of upstreaming, I think we might want to have a more generic version of this, e.g. to also support mobile-linux, which presumably also wants GLES. I guess that would mean introducing an environment variable to control this decision in the build script....
CC @webbeef.

[webbeef]

Yes we need GLES for mobile linux in general. We have a runtime environment variable in surfman to force that (SURFMAN_FORCE_GLES). Having one at build time for webrender is fine.

[jdm]

Would a cargo feature that could be part of Servo's public API be useful here?

[webbeef]

Would a cargo feature that could be part of Servo's public API be useful here?

If we're fine with a build time switch, a cargo feature is probably the best option. There's a benefit with the runtime switch in terms of flexibility (one single build for multiple HW targets) but maybe that does only matter for Linux?

[jschwe]

Both options would be a build-time switch, since this is about pre-generating optimized shaders offline in the build-script. Everything works fine without that, the shaders just need to be compiled on first usage which is either more work, or worst-case results in worse performance if the online compiler of the device is bad at optimising (which at least seems to have been common in 2010, when glslopt was created, no idea if It's still a problem now).

I guess a feature might be nicer / more discoverable than just reading from an environment variable. I guess if neither feature is set we still would do target-specific guessing?

[mrobinson]

What does Firefox do here?

[jschwe]

What does Firefox do here?

I'm a bit confused by the question. I'd assume that Firefox does exactly what the current state of 0.68 is, namely choose GLES vs GL based on the target triple. It doesn't break anything to choose wrong, it's just less optimal since you need to optimise the shaders at runtime (if you got it wrong), which takes time and might have worse runtime performance, depending on the quality of the online optimiser.