[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Wed Mar 18 23:33:06 PDT 2015


On Wed, Mar 18, 2015 at 7:50 PM, Zhenyao Mo <[email protected]> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150319/17e9eba4/attachment.html>


More information about the public_webgl mailing list