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

Re: [Public WebGL] WebGL bufferSubData lacks "size" parameter

I'm a little surprised none of you knows this. But GCing is one of the
*major* pitfalls on writing responsive WebGL applications.

My observations of GC behavior is roughly generalized in these three rules:
- using numbers is ok, it doesn't incur huge GCing stops
- using {}, [], new, function(){} etc. is a big NONO because it causes
the GC to kick in every couple thousand objects or so and halt
*everything* inbetween 120ms to 250ms
- using new typed arrays or views is especially bad on the GC

This GC problematic has lead to a number of undesirable things among them:
- stuttering/jerky apps written by developers who didn't know better
- a slew of math related libraries that go out of their way, to
perform operations without allocating anything, leading to very
stilted and ugly to use API semantics (for instance gl-matrix)
- a marked lack of good 3d structure managing libraries (like
kd-trees, octrees, b-trees, multilevel grids etc.) for dynamic
applications, because operating these structures requires allocation
of branches and leaves, which is not possible at runtime because of
the afmorementioned problems with the GC

As to why 120ms to 250ms might be bad. If you're trying to run a
realtime application at 60fps, these intervals range between 7 to 15
frames. They are *very* noticable.

So I'm very sympathetic to the cause of getting rid of object
allocations in order to shuffle around data. I refute Gregs argument
that it's an unavoidable necessity in JS, because if you write just
plain ugly code that avoids allocations at immense cost to code
maintainability and conciseness of expression, you can avoid a lot
(but not all) allocations.

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