[Public WebGL] WebGL2 and no mapBuffer/mapBufferRange

Florian Bösch [email protected]
Fri Mar 6 13:37:25 PST 2015


I don't think the need to communicate implementation slight implementation
differences justifies adding yet another extension.

On Fri, Mar 6, 2015 at 10:35 PM, Zhenyao Mo <[email protected]> wrote:

> That seems like what developers do for an extension.  You have a shim
> or something for code simplicity, but an understanding that without
> the extension, it doesn't work as well as with it.
>
> To me, it's better being explicit about it rather than implicit. It's
> better for WebGL as a whole, and also better for developers.
>
> On Fri, Mar 6, 2015 at 1:27 PM, Florian Bösch <[email protected]> wrote:
> > If maBufferRange was an extension, here's what I'd do to support it:
> >
> > 1. Write a shim for mapBufferRange using bufferSubData
> > 2. Use that shim that internally switches to the bufferSubData extension
> if
> > available, so that
> > 3. I don't need to bifurcate all my data handling code on 2 functions
> >
> > That's probably just about (in one flavor or other) what everybody would
> do.
> >
> > Anyway, it's not like performance in WebGL was some kind of constant
> value.
> > Platforms you test on routinely have a 10000% performance variance. It's
> > nice if you can accelerate a usecase by 50% or so, very useful too, but
> it's
> > not something you lose sleep over as far as platform differences go.
> >
> > On Fri, Mar 6, 2015 at 10:21 PM, Zhenyao Mo <[email protected]> wrote:
> >>
> >> It's the case where you write and test an app on an efficient
> >> implementation (if we sort out all the BIT control) and expect it to
> >> run the same everywhere else (which is what WebGL core promises) and
> >> then this expectation in reality isn't real.
> >>
> >> On Fri, Mar 6, 2015 at 1:18 PM, Florian Bösch <[email protected]> wrote:
> >> > It's a bit ugly to recast an ES 3.0 core feature as an extension isn't
> >> > it?
> >> >
> >> > Anyway, at worst mapBufferRange is no better than bufferSubData, and
> >> > it'd
> >> > help keep the code simple if you didn't need to write two codepaths
> >> > depending on if you have it available or not.
> >> >
> >> > On Fri, Mar 6, 2015 at 10:12 PM, Zhenyao Mo <[email protected]> wrote:
> >> >>
> >> >> To me the MapBufferRange function seems more fit as an extension
> >> >> rather than part of core for WebGL 2.  We want to preserve the
> >> >> perception that this is something more efficient, but also make sure
> >> >> developers understand that in WebGL 2 this efficiency is not expected
> >> >> everywhere.
> >> >>
> >> >>
> >> >> On Fri, Mar 6, 2015 at 1:48 AM, Mark Callow <[email protected]>
> wrote:
> >> >> >
> >> >> >> On Mar 6, 2015, at 9:59 AM, Mark Callow <[email protected]>
> wrote:
> >> >> >>
> >> >> >> If implementation is a problem, how about requiring that
> >> >> >> MAP_READ_BIT |
> >> >> >> MAP_WRITE_BIT must always be specified?
> >> >> >
> >> >> > Shortly after writing this I realized it is a bad idea but was not
> in
> >> >> > a
> >> >> > position to correct myself until now. Why? Because it forces any
> >> >> > implementation (WebGL or OpenGL) that implements map via copy to
> >> >> > always copy
> >> >> > in both map and unmap.
> >> >> >
> >> >> > I think the reason why these access bits exist is to allow such
> >> >> > implementations to avoid a copy in map (write-only set) or unmap
> >> >> > (read-only
> >> >> > set). For implementations that actually map the buffers I expect
> >> >> > there is
> >> >> > probably no performance difference between single access and RW
> >> >> > access.
> >> >> >
> >> >> > WebGL implementations that would copy during map/unmap could very
> >> >> > easily
> >> >> > enforce errors for bad applications without any changes to
> >> >> > ArrayBuffers by
> >> >> > not copying, as described above and providing a buffer initialized
> to
> >> >> > 0 for
> >> >> > the write-only case to prevent data leakage.
> >> >> >
> >> >> > Unfortunately the only way I see for WebGL implementations that
> would
> >> >> > actually map buffers to work is to specify RW when calling the
> >> >> > underlying
> >> >> > OpenGL. This would be fine for correct applications (see above
> about
> >> >> > performance), but would mean that bad applications would run
> without
> >> >> > error.
> >> >> > Thus bad apps would work in some implementations but not on others
> >> >> > which is
> >> >> > unacceptable for WebGL.
> >> >> >
> >> >> > So I think supporting MapBuffer does require read-only and
> write-only
> >> >> > ArrayBuffers.
> >> >> >
> >> >> > Regards
> >> >> >
> >> >> >     -Mark
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20150306/4992c5c8/attachment.html>


More information about the public_webgl mailing list