Support mipmap texture filters

[Dave Jeffrey]

Currently only linear and nearest filters are supported for textures. WebGL also allows mipmap filters for MIN filter (GL_NEAREST_MIPMAP_NEAREST, GL_LINEAR_MIPMAP_NEAREST, GL_NEAREST_MIPMAP_LINEAR and GL_LINEAR_MIPMAP_LINEAR).

Using mipmaps can lead to better visual quality as the downscaled versions of a texture can be pre-filtered or even hand-manipulated, but can also lead to vastly better performance. For example, rendering a large texture many times (like a tiled pattern) ends up being slow because of the bandwidth overhead of each tile draw operation utilising the entire texture.

More details on the mipmap filters available to WebGL can be found here: https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexParameter.xml

I'm happy to submit a PR if this issue is accepted.

[Andrey Kuzmin]

If we implement this, we might also need to add support for GL_TEXTURE_WRAP_S and GL_TEXTURE_WRAP_T. With all of this we can support non power of two textures.

[Florian Zinggeler]

May I add cubemaps?
With this we'd cover pretty much all of textures.
Plus implementation wise it should be almost the same.

EDIT: bummer, this would require a compiler change, as we'd need the new glsl type samplerCube to be inferred by the compiler. Maybe in elm 0.19?

At least the changes would be trivial, here the relevant compiler lines:
https://github.com/elm-lang/elm-compiler/blob/master/src/AST/Literal.hs#L26
and here:
https://github.com/elm-lang/elm-compiler/blob/master/src/Parse/Helpers.hs#L565

[Andrey Kuzmin]

@Zinggi we own the native part and can use this info from the texture value. It doesn't have to be a different type.

Oh, sorry, you're right, the compiler will then let any texture as cubemap.

[Andrey Kuzmin]

@lepoetemaudit which api would you prefer for loadWith : TextureOptions -> String -> Texture:

1. { minFilter, magFilter, wrapS, wrapT } following the standard naming
2. { minifyingFilter, magnifyingFilter, horizontalWrap, verticalWrap } more descriptive

[Dave Jeffrey]

@w0rm I would prefer the more descriptive names. OpenGL is not a benchmark for good naming in my opinion.

[Andrey Kuzmin]

@lepoetemaudit ok I will use it, and maybe provide the original naming in the comment, so it will be searchable.

[Andrey Kuzmin]

What about gl.pixelStorei? The current implementation enables gl.UNPACK_FLIP_Y_WEBGL that I heard someone found a bit unexpected. Check this issue elm-community/elm-webgl#36

Our options are:

1. keep the existing functionality
2. remove UNPACK_FLIP_Y_WEBGL
3. add support for pixelStorei

I checked the documentation and vote to keep the existing functionality, because we don't have any use cases for this.

[Andrey Kuzmin]

I also wonder why the old implementation https://github.com/elm-community/webgl/blob/master/src/Native/WebGL.js#L86 used Linear that goes against WebGL defaults for minification filter that is gl.NEAREST_MIPMAP_LINEAR

[Florian Zinggeler]

... keep the existing functionality, because we don't have any use cases for this.

I agree. It would just make it needlessly more complex for little gain.

... why the old implementation used Linear that goes against WebGL defaults ..

I'd change it to the default WebGL behavior. It's just a texture filter option, so which one is used won't be very apparent anyway, and sticking with WebGL default sounds less surprising to me.

[Andrey Kuzmin]

@Zinggi I added flipY support, I actually remembered that it was confusing for me when I needed to calculate the location of the frame in the sprite.