[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] ARB_texture_storage for WebGL

> On Sep 8, 2015, at 7:27 AM, Кирилл Дмитренко <dmikis@yandex-team.ru> wrote:
> Greetings!
> I'm digging into ANGLE and how it works. Recently I've read in the WebGL Insights book that ANGLE doesn't really like when an application
> changes dimensions or mipmapping of a texture. If I understand it correctly, that is due to the fact that D3D doesn't allow to change texture parameters once it's created. Also, there is a note in the book that texStorage* calls allow ANGLE to overcome this problem (in other words, handle textures more efficiently). But why don't we have those calls as an extension to WebGL, i.e. ARB_texture_storage?

ARB_texture_storage does not solve the general problem of changing dimensions and mipmapping of a texture whenever you want. What it does solve is that it allows the application to provide all the information about the shape and format of the texture up front before you load any data. Once created these things cannot be changed. Hence the problem texture_storage solves is to remove the need for changes when making textures that differ from defaults set when a texture is created by gl.bindTexture. However this problem can be largely alleviated by the implementation by lazy creation of its internal texture structures. That is, waiting until the first call to gl.texImage*D before creating them.

So texture_storage is really about allowing simpler drivers. The problem is not unique to ANGLE which is why the extension exists.



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail