[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange
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
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
- WEBGL_mapbuffer_basic (contains glMapBuffer[Range])
- WEBGL_mapbuffer_inval (for when write|inval has a caveat, contains
- WEBGL_mapbuffer_async (for when write|async has a caveat, contains
- WEBGL_mapbuffer_??? (for when write|async|inval has a ceaveat)
You see the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl