New Z elevation feature! Plus new template, performance improvements and more.
This is actually very difficult to do, because in WebGL 1 samplers and textures aren't separated, so you have to specify the sampler when loading the texture.
Let the action check if the device is running WebGL 2. If not, don't do any changes to the sampling mode and return an error message in the browser console?
Another option could be applying the setting on a layout change and forcing a complete reload I guess?
I'm not sure if that's something you'd like to implement though.
In general we try to avoid device-specific features, since they complicate the codebase significantly (in this case making two separate paths for handling sampling). This involves more development work and more difficult bugs (e.g. issues that only happen in a specific WebGL version which are harder to diagnose and fix). If we do this a lot then it gets even worse as you can end up with issues that only occur on devices that match three or four requirements, which turns in to a major time-sink, which we just can't afford with our limited resources. Sometimes we can justify it for a major feature, but I don't think this qualifies, it seems like it's just a nice-to-have.
I think the 2nd option I mentioned could be applied to both and you'd just need to check if WebGL is supported at all. Even if WebGl2 doesn't technically require it, it could be used there too, keeping the code base the same.
I'm not familiar with the differences between WebGL 1 and 2, so this is pretty much just speculation on my part.
For me personally it's a nice-to-have but I don't know how important it would be for others. I assume mobile dev's could make something out of this feature?
It's still complicated to do that - there are no other features that require a layout restart to apply a change at runtime, and currently restarting a layout does not reload any textures because it knows it's using the same set of textures. So there's a new codepath to write for 'reload layout and also reload all textures as if it's a different layout', which will need separate implementation and testing to a normal 'restart layout'. I'd be more persuaded this was worthwhile if you actually had benchmark numbers showing this made a significant difference for a particular game.
Alright, makes sense. Although I see implementing such a system in a modular way, as a benefit for future suggestions (e.g. layout-to-layout loading customization).
I'm not sure how that benchmark would look like. I'd have to measure the rendering performance somehow, do any of the existing performance examples cover this? I don't want to provide something, that's going to be dismissed because it measures things unrelated to this feature.
It would mostly affect GPU texture read performance. I'm not sure we have a performance test that directly covers that, but the fillrate test is probably closest.
I've used all the included performance tests and some of my own. Using a mid-range PC, there is no noticeable difference in performance.
Since I'm mainly developing for desktops, I'd consider this feature to be a nice-to-have in the future. I'm not sure how low-end mobile systems would perform but I guess the performance gains would be minimal at best.
Thanks for the responses!