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?

-Won

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
-----------------------------------------------------------

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