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

Re: [Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

On Wed, Mar 18, 2015 at 7:50 PM, Zhenyao Mo <zmo@chromium.org> wrote:
That's exactly my point.  This sounds exactly like an candidate of an
extension, that developers will be forced into the awareness that the
"sharp" tool may not exist everywhere.

An extension "singular" isn't a solution. Let's run with the premise that significant performance caveats remain unresolvable between different implementations (I'm not convinced of that premise as I believe those caveats can largely be avoided, but for the sake of argument, let's assume you're right).

An extension communicates 1 bit in capabilities (present or absent, 1 or 0). But from all the discussion about this, it does seem to me that you'd imply that there exist at least a couple performance caveat bits (like maybe 3 or 4?) depending on the assemblage of flags you'd use.

The test of "Is this a good bit of information to pack into an extension" is the following question: "Does all that is contained in the extension fall into a 1-bit sized bucket?". The answer to this for glMapBuffer[Range] is (going by your theories) is no. It doesn't. You'd need a couple new extensions (like 3 or 4?) to communicate more bits.

Even if we assume we'd want to provide multiple extensions to convey all the performance caveat bits of glMapBuffer[Range] (most assuredly, we don't), defining such an extension set would be difficult because the conditions for caveats do not depend mutually exclusive sets of functions/flags. They appear in combinations of them. So for instance, you could have:
  • WEBGL_mapbuffer_basic (contains glMapBuffer[Range])
  • WEBGL_mapbuffer_inval (for when write|inval has a caveat, contains INVALIDATE_*)
  • WEBGL_mapbuffer_async (for when write|async has a caveat, contains UNSYNCHRONIZED_BIT)
  • WEBGL_mapbuffer_??? (for when write|async|inval has a ceaveat)
You see the problem.