- Original Message -
Sorry for joining the conversation late.
On Mar 28, 2012, at 1:39 PM, Kenneth Russell wrote:
On Wed, Mar 28, 2012 at 12:34 PM, Benoit Jacob bja...@mozilla.com
wrote:
1. In webgl.bufferData implementation, don't call glBufferData,
instead just cache
Sorry for joining the conversation late.
On Mar 28, 2012, at 1:39 PM, Kenneth Russell wrote:
On Wed, Mar 28, 2012 at 12:34 PM, Benoit Jacob bja...@mozilla.com wrote:
1. In webgl.bufferData implementation, don't call glBufferData, instead just
cache the buffer data.
2. In
On Wed, Mar 28, 2012 at 5:33 PM, Charles Pritchard ch...@jumis.com wrote:
It does seem like a bigger warning in the spec may benefit developers.
A warning and an example of how to check for big-endian results.
Asking developers to write extra code paths for users that don't exist is
futile.
On 3/28/12 12:49 AM, Robert O'Callahan wrote:
On Wed, Mar 28, 2012 at 5:33 PM, Charles Pritchardch...@jumis.com wrote:
It does seem like a bigger warning in the spec may benefit developers.
A warning and an example of how to check for big-endian results.
Asking developers to write extra
On 3/28/2012 12:49 AM, Robert O'Callahan wrote:
On Wed, Mar 28, 2012 at 5:33 PM, Charles Pritchardch...@jumis.com wrote:
It does seem like a bigger warning in the spec may benefit developers.
A warning and an example of how to check for big-endian results.
Asking developers to write extra
On 3/28/12 12:59 AM, Charles Pritchard wrote:
I've no desire to coddle low-level coders. They know what they're
getting into.
You're making the mistake of thinking that people using typed arrays are
low-level coders, whereas in reality everyone and their mother is
being told to use the
On 3/28/2012 12:57 AM, Boris Zbarsky wrote:
On 3/28/12 12:49 AM, Robert O'Callahan wrote:
On Wed, Mar 28, 2012 at 5:33 PM, Charles Pritchardch...@jumis.com
wrote:
It does seem like a bigger warning in the spec may benefit
developers.
A warning and an example of how to check for big-endian
On 3/28/2012 1:05 AM, Boris Zbarsky wrote:
The general position of this group, indeed the main reason for its
existence, is that specs should reflect reality and that a spec that
is deliberately misleading in terms of what it takes to achieve
interoperable behavior is not much better than no
On Wed, Mar 28, 2012 at 8:59 PM, Charles Pritchard ch...@jumis.com wrote:
I consider your position one of benevolent paternalism. You are free to
stick with it, and to apply it in your patch submissions.
I've no desire to coddle low-level coders. They know what they're getting
into.
I'm
On 3/28/2012 1:03 AM, Robert O'Callahan wrote:
On Wed, Mar 28, 2012 at 8:59 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
I consider your position one of benevolent paternalism. You are
free to stick with it, and to apply it in your patch submissions.
I've no
On Wed, Mar 28, 2012 at 9:14 PM, Charles Pritchard ch...@jumis.com wrote:
When you or Robert disparage developers as a class, that is harmful.
I apologise for being careless in my language. I don't intend to cast
aspersions on developers, and I should choose my words more carefully to
make
On 3/28/12 1:14 AM, Charles Pritchard wrote:
Most developers work with multiple programming languages. They read
manuals, they read blogs, they try things out, and then they often code
more in other languages than in JS.
Are you sure this is true for most developers creating web content?
But
On 3/28/12 1:22 AM, Charles Pritchard wrote:
You are making the assertion that deliberately misleading in terms of
what it takes to achieve interoperable behavior.
Yep.
And you and Robert have given reasons why you believe developers will
make many mistakes.
No, I'm just saying developers
On Wed, Mar 28, 2012 at 1:03 AM, Robert O'Callahan rob...@ocallahan.org wrote:
On Wed, Mar 28, 2012 at 8:59 PM, Charles Pritchard ch...@jumis.com wrote:
I consider your position one of benevolent paternalism. You are free to
stick with it, and to apply it in your patch submissions.
I've no
On 3/28/12 2:04 AM, Jonas Sicking wrote:
Consider a big-endian platform where both the CPU and the GPU is
big-endian. If a webpage writes 16bit data into an ArrayBuffer and
then sends that off to the GPU using WebGL, the data had better be
sent in big-endian otherwise the GPU will interpret it
On Wed, Mar 28, 2012 at 2:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/28/12 2:04 AM, Jonas Sicking wrote:
Consider a big-endian platform where both the CPU and the GPU is
big-endian. If a webpage writes 16bit data into an ArrayBuffer and
then sends that off to the GPU using WebGL, the
On 28/03/2012 18:13, Boris Zbarsky wrote:
What one could do is to store the array buffer bytes always as little
endian, and then if sending to the GPU byte-swap as needed based on
the API call being used (and hence the exact types the GPU actually
expects).
So basically, make all
On 3/28/12 2:32 AM, Mark Callow wrote:
Then, if you are on a big-endian system an app will not be able to read
write int, float, etc. into the int32Array, float32Array, etc.
Why not?
-Boris
On 28/03/2012 18:33, Boris Zbarsky wrote:
On 3/28/12 2:32 AM, Mark Callow wrote:
Then, if you are on a big-endian system an app will not be able to read
write int, float, etc. into the int32Array, float32Array, etc.
Why not?
Because you said JS-visible state (will) always be
On 3/28/12 2:22 AM, Jonas Sicking wrote:
Except if the data was written in 32bit units you do a different byte
swapping than if the data was written as 16bit units.
Hmm. I just read the webgl spec more carefully and discovered that
bufferData() actually takes a byte array whose structure is
On 3/28/12 2:40 AM, Mark Callow wrote:
On 28/03/2012 18:33, Boris Zbarsky wrote:
On 3/28/12 2:32 AM, Mark Callow wrote:
Then, if you are on a big-endian system an app will not be able to read
write int, float, etc. into the int32Array, float32Array, etc.
Why not?
Because you said
On 28/03/2012 18:45, Boris Zbarsky wrote:
On 3/28/12 2:40 AM, Mark Callow wrote:
Because you said JS-visible state (will) always be little-endian.
So? I don't see the problem, but maybe I'm missing something...
The proposal is that if you take an array buffer, treat it as a
Uint32Array,
On 3/28/12 3:01 AM, Mark Callow wrote:
So now you are saying that only the JS-visible state of ArrayBuffer is
little-endian.
The JS-visible state of conversions from multi-byte-sized quantities to
bytes or back is little-endian.
The JS-visible state of int32Array, etc. is in
vertexAttribPointer lets you specifiy to WebGL the layout and type of
the data in the buffer object. The API follows OpenGL {,ES} for
familiarity and reflects its heritage of a C API avoiding use of
structures. But it works.
OpenGL {,ES} developers typically load data from a serialized form and
On 2012-03-28 12:01, Mark Callow wrote:
On 28/03/2012 18:45, Boris Zbarsky wrote:
On 3/28/12 2:40 AM, Mark Callow wrote:
Because you said JS-visible state (will) always be little-endian.
So? I don't see the problem, but maybe I'm missing something...
The proposal is that if you take an
On 3/28/12 3:14 AM, Mark Callow wrote:
vertexAttribPointer lets you specifiy to WebGL the layout and type of
the data in the buffer object.
Sure. That works for the GPU, but it doesn't allow for the sort of
on-the-fly endianness conversion that would be needed to make webgl
still work on
Personally, I think TypedArrays are too closely tied to WebGL -- as they
become part of JS and not just tied to WebGL (for example, IE10 will
support TypedArrays but not WebGL), they are going to be used for other
things. For example, reading/writing binary file formats or exchanging
wire
On Wed, Mar 28, 2012 at 3:46 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/28/12 3:14 AM, Mark Callow wrote:
vertexAttribPointer lets you specifiy to WebGL the layout and type of
the data in the buffer object.
Sure. That works for the GPU, but it doesn't allow for the sort of
on-the-fly
Before I joined this mailign list, Boris Zbarsky wrote:
C) Try to guess based on where the array buffer came from and have
different behavior for different array buffers. With enough luck (or
good enough heuristics), would make at least some WebGL work, while also
making non-WebGL things
On Wed, Mar 28, 2012 at 12:34 PM, Benoit Jacob bja...@mozilla.com wrote:
Before I joined this mailign list, Boris Zbarsky wrote:
C) Try to guess based on where the array buffer came from and have
different behavior for different array buffers. With enough luck (or
good enough heuristics),
I was initially on the just make it little endian and don't make me worry
about it side of the fence, but on further careful consideration I've
changed my mind: I think having typed arrays use the platform endianness is
the right call.
As Ken pointed out, if you are populating your arrays from
On Wed, Mar 28, 2012 at 2:27 PM, Brandon Jones toj...@gmail.com wrote:
I was initially on the just make it little endian and don't make me worry
about it side of the fence, but on further careful consideration I've
changed my mind: I think having typed arrays use the platform endianness is
the
On Wed, Mar 28, 2012 at 2:08 PM, Kenneth Russell k...@google.com wrote:
The top priority should be to implement DataView universally.
DataView isn't relevant to the discussion. People are using
ArrayBufferViews in ways that assume little-endian access, and that isn't
going to go away. If any
On Thu, Mar 29, 2012 at 8:08 AM, Kenneth Russell k...@google.com wrote:
Once DataView is available everywhere then the top priority should be
to write educational materials regarding binary I/O. It should be
possible to educate the web development community about correct
practices with only a
On Wed, Mar 28, 2012 at 7:30 PM, Glenn Maynard gl...@zewt.org wrote:
And for all realistic purposes, the world has standardized on
little-endian.
Other than network protocols, which are all big-endian.
--
John A. Tamplin
Software Engineer (GWT), Google
On Wed, Mar 28, 2012 at 6:52 PM, John Tamplin j...@google.com wrote:
On Wed, Mar 28, 2012 at 7:30 PM, Glenn Maynard gl...@zewt.org wrote:
And for all realistic purposes, the world has standardized on
little-endian.
Other than network protocols, which are all big-endian.
I'm talking about
On Wed, Mar 28, 2012 at 8:04 PM, Glenn Maynard gl...@zewt.org wrote:
The result was increased polymorphism at call sites, which defeated the
Java VM's
optimizing compiler and led to 10x slowdowns in many common
situations.
FWIW, I think this has no bearing at all on JS.
Check out this
On Wed, Mar 28, 2012 at 7:11 PM, John Tamplin j...@google.com wrote:
On Wed, Mar 28, 2012 at 8:04 PM, Glenn Maynard gl...@zewt.org wrote:
The result was increased polymorphism at call sites, which defeated the
Java VM's
optimizing compiler and led to 10x slowdowns in many common
On Wed, Mar 28, 2012 at 8:50 PM, Glenn Maynard gl...@zewt.org wrote:
Maybe I misunderstood what he was referring to; I was thinking about the
comparative cost of making, say, a C++ function virtual (added dispatch
cost). It wouldn't make calls to functions any more polymorphic--you
already
On Wed, Mar 28, 2012 at 8:21 PM, John Tamplin j...@google.com wrote:
I assumed the point Kenneth was making that you objected to was that if
you had Uint16BEArray and Uint16LEArray, so you could have both native
(with Uint16Array being one of them) and specific endian-ness was that you
are
On Thu, Mar 29, 2012 at 2:21 PM, John Tamplin j...@google.com wrote:
a = someFunctionReturningUint16ArrayWhichMightBeLEorBE();
a[4] = 100;
the call to store into a might need to call Uint16LEArray or
Uint16BEArray.storeInto under the hood. If you only ever use one, then the
JIT'er can just
On Wed, Mar 28, 2012 at 3:43 PM, Kenneth Russell k...@google.com wrote:
Production browsers already implement typed arrays with their current
semantics. It is not possible to change them and have WebGL continue
to function. I will go so far as to say that the semantics will not be
changed.
On 3/27/12 8:42 PM, Robert O'Callahan wrote:
On Wed, Mar 28, 2012 at 3:43 PM, Kenneth Russellk...@google.com wrote:
Production browsers already implement typed arrays with their current
semantics. It is not possible to change them and have WebGL continue
to function. I will go so far as
43 matches
Mail list logo
