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

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



On Fri, Mar 6, 2015 at 2:13 PM, Florian Bösch <pyalot@gmail.com> wrote:
> On Fri, Mar 6, 2015 at 10:55 PM, Zhenyao Mo <zmo@chromium.org> wrote:
>>
>> 1) We can't expose INVALIDATE_BUFFER bit
>
> Please elaborate.

Undefined buffer values.

>
>>
>> 2) We can't expose FLUSH bit with mapping implementations (we can only
>> allow it in copying implementations), therefore also not
>> glFlushMappedBufferRange() for mapping implementations.
>
> Please elaborate.

Again, undefined buffer values between write and flush (if you forget to flush)

In copying implementations, we can hold on any writes until flush
time, so if you use the buffer between writes and flush, you get the
old data; but not for mapping implementations.

>
>>
>> You lose perf in copying implementation, lose functionality in mapping
>> implementation.  In my opinion, defining it as an extension is the
>> clearest way to expose the subset of them.
>
> I'm strictly against recasting core functionality as an extension. It's
> unprecedented and in my opinion not user friendly. I'm also strictly against
> dropping core functionality. Even if it's inconvenient not to drop it. I'm
> against it because it means you're not producing an ES 3.0 compatible
> implementation. That creates all sorts of issues, among them issues for
> people who transpile to it, and issues for what "a khronos ratification"
> means for an implementation as well as issues for what you'll do in future
> revisions of the specification.
>
> It's easy to see how such a bifurcation of the specifications will lead to
> WebGL being a completely distinct variant of GL from either Desktop GL and
> ES.

I am totally OK with unprecedented cases.  All inventions are
unprecedented. In my opinion exposing these functions in the core is
not developer friendly. That's where you and I differ.

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