Thank you for this opportunity. During evaluating of different techniques to bring 3D games to the browser the missing texture compression support was one of the cons for WebGL. There are three primary reasons why we would like to see compression support:
1. Reducing the download time for the players. We still have many customers with slower (~1 MBIt/s) connections.
2. Reducing the bandwidth cost. This may not a problem for many sites today but if we deliver game content to Millions of people this would require quite an amount of bandwidth that is not for free.
3. Improving performances for people with lower class GFX hardware. To be honest I am not sure if we will run in memory limitations before we hit the limit of the script engine. But as the script engines improve faster than the hardware it is likely.
Therefore I would like to see two features for the compressed texture support:
1. Allow downloading data for different compression methods separately. We already can (and need) handle this well for different sound formats so there is no magic behind this. A combined storage for all formats could be fine for people who don’t care that much about bandwidth but as said we prefer to only transfer data to the client that could be used there.
2. Allow separated transfer of the different mip levels. This way we could stream the lower resolutions first.
3. Make it somewhat generic. I think the standards don’t need to list the supported formats itself. Just a way to tell the application what is supported would be enough. This way there would no need to update the standard if a new format shows up.
Von: firstname.lastname@example.org [email@example.com] im Auftrag von Gregg Tavares (wrk) [firstname.lastname@example.org]
Gesendet: Sonntag, 23. Oktober 2011 07:38
An: public webgl
Betreff: [Public WebGL] Texture Compression in WebGL
If you're a developer making a WebGL app please tells us your needs and opinions regarding WebGL supporting texture compression.
There's been some discussion of this among the various implementers of WebGL but it would be helpful to have more input from actual developers.