tl;dr: get rid of GetYCoordScale() and handle the GLES NDC transformation internally, removing a hazardous abstraction leak that we don't need. Impeller internals, if you know you know.

This is a sad landmine that has regularly exploded on us and will continue to do so until the end of time. Chinmay and I landed the current solution years ago after we saw it in a Unity doc because neither of us could think of anything better at the time and we had much bigger fish to fry.

We don't need to leak this GLES-specific backend eccentricity into Impeller's 2D renderer (or FragmentProgram shaders, or Flutter GPU).

First off, to be more efficient than what we're doing today: we can inject a single uniform for performing the conditional flip to gl_Position.y in the vertex stage when the offscreen FBO itself is being rendered to, as opposed to Impeller's current solution of injecting one uniform per sampler in the fragment stage so that we can handle flipping offscreen textures that were already rendered upside-down. Then we just flip the winding order for the command in the RenderPass. This is the solution that wgpu/ANGLE/Filament all internally employ to great effect.

So, we'd handle this detail internally within the GLES backend, hiding this eccentricity from Impeller's 2D renderer (and Flutter GPU) entirely, by:

• Writing a special uniform into all GL vertex stage shaders in impellerc & flipping gl_Position.y with it:

  // Hidden uniform inserted into every vertex shader compiled for a GL target.
  // Set by RenderPassGLES per pass.
  uniform float _impeller_y_flip;
  
  // Appended after the user's main():
  gl_Position.y *= _impeller_y_flip;

• While encoding GLES commands set the special uniform to -1.0 and flip the winding order.

Note that GLES 2 only has room for 16 vec4s in the fragment stage and has 128 vec4s in the vertex stage. So we're going from taking up 1 uniform per sampler in a pretty constrained environment to only ever using 1 in an environment where there's plenty of bandwidth to go around. So we don't have to worry about the uniform bandwidth as much. 😀 Running out of uniforms in the fragment stage was a real problem for us back when some of the contents were being initially implemented.

What other HALs do today

Surveying the five HALs that most closely match Impeller's position:

Two clusters: HAL-absorbs-it (wgpu, ANGLE, Filament) and app-handles-it-via-caps (bgfx, sokol_gfx). Of the three that absorb it in the HAL, all three apply the compensation at the vertex output, not at texture sampling. Nobody else does what Impeller does today (per-sampler uniforms threaded through every sampling site).

Three of three Google-maintained HALs in this space (Dawn/Tint, ANGLE, Filament) absorb the work, with the only meaningful design choice being how (vertex-shader rewrite for ANGLE and Tint, a Vulkan extension for Filament). The pattern below is the ANGLE shape because it gives us the per-pass conditional control the Impeller use case actually needs.

Where Y-flip lives in Impeller today

Roughly 20 sites threading the same value through the same pattern, with the per-shader application written by hand each time. Retiring them is the cleanup payoff of this proposal.

Bugs traceable to the current design

The pattern is the same each time: a new site samples a kRenderToTexture texture, nobody threads y_coord_scale, the result is upside-down on GLES. The cadence is roughly one a year inside Impeller and it has now started leaking into ecosystem code built on flutter_gpu. Removing the design takes the bug class out of the per-contributor-discipline category.