[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] ETC texture compression.
Chris Marrin wrote:
> Assuming the copyright issues for ETC1 get sorted out I think we
> should just make it a part of the spec rather than an extension. The
> availability of a software decoder would allow it to be implemented on
> platforms without ETC1.
The problem with resorting to software decoders is that most (if not
all) desktop systems don't provide support for ETC1. You'd package your
textures into ETC1, suffer the horrific loss of image quality...and then
discover that you're actually not saving any video memory or improving
texture cache coherency at all! ETC1 does help your network bandwidth
(the files are 6:1 compressed) - but the average file compression rate I
get from PNG's zlib compression is 3.6:1 (averaged over all the maps in
my game) - so the network bandwidth savings from ETC are less than a
factor of two over PNG. Given that, I can't imagine many people
preferring ETC1 over PNG for desktop systems.
Of course on phones, (where it's implemented) ETC1 will be very useful
indeed - and on those teeny-tiny displays, the loss of quality isn't so
critical as it is on a 28" 1600x1400 monitor. So many implementors will
end up having to treat ETC1 as if it was an extension and avoid using it
on desktop hardware.
But here is the problem...if ETC1 becomes a core feature - but doesn't
actually do any compression on desktop platforms - how the heck does the
implementation know whether it's useful or not?
At the very least - if we make ETC1 into core feature - there needs to
be a way to ask the API "Hypothetically: What compression ratio would I
get for such-and-such format texture in such-and-such internal-format
pixels on this hardware?"
* On desktops & laptops that don't support ETC, this function would
report 1.0 for both PNG and ETC.
* On phones that support ETC and 8/8/8/8 textures, it would report 1.0
for PNG and 6.0 for ETC.
* On phones that can only do ETC or 5/6/5/0. 5/5/5/1 or 4/4/4/4, it
would report 2.0 for PNG and 6.0 for ETC.
That would allow the application to make rational decisions about which
format of file to grab from the server.
If we're going to handle ETC2 similarly in the future, and we know for
sure that no current system supports it - then we'd need to decide
whether to use that too.
But simply making ETC1 magically work if the file extension is ".etc"
without any other help would be a bad way to handle it.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: