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

Re: [Public WebGL] webgl tests seem to require 24/32-bit canvas buffer

I'd prefer requiring 8bits. We require 8bit textures as render targets to be supported and so any WebGL impl can therefore use an 8bit texture as its backbuffer.

But, I don't mind updating whatever tests need to be updated for lower spec stuff.
Note that it's not just a tests update that we need here, it's a spec update. Section 2.2 requires 8 bits per channel.
Some of the tests already attempt to do this but since I don't have access to any low end hardware I haven't been able to check them.

On the other hand, I'm not sure I agree with the desire to pull along crappy low-end hardware to the detriment of all of WebGL. Is there current hardware that is using 4/4/4/4 or 5/5/5/1? I think that discussion would be had. I think the argument could be made that we shouldn't try to make WebGL run on low-end hardware. An iPad2 level GPU machine is now selling for $35 (the Raspberry Pi) or $50 (the APC.io) do we really need to go lower?
We're not talking about lower-than-Raspberry-Pi levels here. We're talking about recent enough Android phones (Would be nice to have specific model names here - Vlad?)

The cost in terms of visual quality seems low. 4444 dithered looks close enough to 8888 on a phone screen that you have to pay attention and look very close to see the dithering. 565 looks even better. It's unfortunate that we have alpha by default, so many pages will use 4444 instead of 565 even though they don't need the alpha, but 4444 still looks good enough that it doesn't matter in practice.

Won: would you have an example of a WebGL page that does lots of blending, to test?


On Tue, Jul 10, 2012 at 11:35 AM, Won Chun <wonchun@google.com> wrote:

On Tue, Jul 10, 2012 at 2:23 PM, Vladimir Vukicevic <vladimir@mozilla.com> wrote:

----- Original Message -----
> I recall that the topic of using a 5_6_5 or 4_4_4_4 renderbuffer came
> up during the last conference call.
> From a quality of implementation standpoint, are you sure that WebGL
> should allow the default back buffer to be 5_6_5? I am not convinced.
> The visual quality will be significantly lower, and developers will
> need to either test on such hardware, or some sort of emulation
> mechanism must be added so that they can get this behavior on desktop
> machines (not easy). This topic was discussed a long time ago in the
> working group, and the consensus was that implementations should
> require a minimum of 8 bits per channel. That requirement is defined
> in the spec: http://www.khronos.org/registry/webgl/specs/latest/#2.2

Well, it'll be "lower" on mobile hardware, but it'll match the look (and performance) of native apps in this way.  I just tested some demos with 4/4/4/4 and they all look fine to me (because of alpha:true being the default); dithering is also enabled by default, so apps don't have to do anything special to get good looking results.  One option is that we add an 'optimizeQuality' context attribute, much like there is in CSS.  It seems like a mistake to require 8 bits per channel for webgl on devices that are already performance limited compared to the desktop, and where native apps tend to be 565 anyway.

Did you test demos that did lots of blending? What hardware did you try this on? I believe PowerVR is deferred, so can do much of its blending in on-chip memory (so-called "Internal True Colour"). How is it on Tegra?


If we want to let people test this on the desktop, that shouldn't be too hard; ANGLE already exposes 565 render targets I thought, and recent desktop GL should let you create a 565 texture/framebuffer...

> From the last concall, it sounded like the main reason for switching
> to a lower precision color buffer was performance. Have you tried
> hooking up
> http://www.khronos.org/registry/gles/extensions/EXT/EXT_discard_framebuffer.txt
> to your WebGL implementation? The "preserveDrawingBuffer" context
> creation attribute was specifically designed to allow implementations
> to use EXT_discard_framebuffer to reduce memory traffic on tiled
> OpenGL implementations.

I think that's orthogonal -- it should provide a speedup regardless of whether the framebuffer is 32-bit or 16-bit, no?  But we haven't hooked it up yet; it's on the list for sure, though.

   - Vlad

> On Tue, Jul 10, 2012 at 9:01 AM, Benoit Jacob <bjacob@mozilla.com>
> wrote:
> >
> > The right way seems to be to fix the tests that require
> > 8-bit-per-channel. The tests should probably use getParameter to
> > query the color depth and adjust their precision requirement
> > accordingly.
> >
> > Notice that since this should be fixed in the trunk version of the
> > conformance tests, and Mozilla's copy is still 1.0.1, we'll have
> > to either do the fixes twice or first update our copy to trunk.
> >
> > Mozilla-specific: Meanwhile, in order to land these changes ASAP,
> > have you considered temporarily marking these tests as
> > known-to-fail on android? Or are there really too many of them?
> >
> > Benoit
> >
> > ----- Original Message -----
> >>
> >> Hi all,
> >>
> >> I just discovered that the webgl tests seem to require a full
> >> 24-bit/32-bit canvas buffer on many tests, since they expect to
> >> draw
> >> and then readPixels back specific values which won't match up if
> >> the
> >> canvas is 5/6/5 or 4/4/4/4.  This is unfortunate, since we really
> >> want to choose a 565 format for the canvas on mobile if we can :)
> >>  One solution would be to create a framebuffer for the tests that
> >> need exact color values to execute in, and to fix up the few that
> >> don't really.  I suppose we could also add a hidden pref in
> >> Firefox
> >> to always request a 24/32-bit buffer and run the tests with that
> >> in
> >> the meantime, but I think the tests should be passable as-is when
> >> rendered to a 565 buffer.
> >>
> >>     - Vlad
> >>
> >> -----------------------------------------------------------
> >> You are currently subscribed to public_webgl@khronos.org.
> >> To unsubscribe, send an email to majordomo@khronos.org with
> >> the following command in the body of your email:
> >> unsubscribe public_webgl
> >> -----------------------------------------------------------
> >>
> >>
> >
> > -----------------------------------------------------------
> > You are currently subscribed to public_webgl@khronos.org.
> > To unsubscribe, send an email to majordomo@khronos.org with
> > the following command in the body of your email:
> > unsubscribe public_webgl
> > -----------------------------------------------------------
> >

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl