[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2
To try to pull things back on topic, my proposal only affects uploads
of ArrayBufferViews. FlipY and PremultAlpha for uploads of DOM objects
is more constrained and has stronger use cases.
Are there any objections for why ArrayBufferViews benefit from having
FlipY and PremultAlpha unpack options? This certainly isn't in GLES.
Conceptually, the user should prepare the contentes of their buffer,
including orienting it and premultiplying alpha (if desired) before
asking GL to upload it.
Mature performance-aware apps will ensure that their data is baked in
a form which is as-ready-as-possible for immediate upload.
We can, of course, tolerate keeping only the
backwards-compatibility-necessary behavior. My main concern is the new
exploding combinatorics that WebGL 2's new UNPACK_ settings and new
On Fri, Nov 6, 2015 at 5:18 AM, Ashley Gullen <email@example.com> wrote:
> Yes, the use case is for JS to do pixel-manipulation operations before
> passing to WebGL. For example in texture atlases to prevent
> color/transparency bleed-in from outside the image area, it's useful to
> repeat the outer border of pixels just outside the image. Canvas is
> unsuitable for per-pixel operations like that, especially if the browser
> tries to GPU-accelerate the context. So in that case JS would obtain an
> ImageData, write to some entries, then pass it (in whole or in chunks) to
> Modifying canvas2d's getImageData() is no help, because it is the worst way
> of getting ImageData (often does synchronous main-thread image decoding) and
> needs to be replaced. Perhaps there could be a method like
> ImageData.premultiply()? But that doesn't help with the case of uploading
> other types like Image, Canvas, Video...
> On 5 November 2015 at 16:45, Olli Etuaho <firstname.lastname@example.org> wrote:
>> What's the exact use case for uploading textures from ImageData? Is the
>> idea that the image needs to go through some changes, like color adjustments
>> in JS before being uploaded to WebGL? Otherwise it seems simpler to just use
>> the entry points that upload images directly, which would still have the
>> WebGL conversion flags in Jeff's proposal. Maybe this use case should rather
>> be solved by adding flags to getImageData() that would make it return
>> premultiplied (or possibly flipped) data, as that would also have the
>> benefit of avoiding the possible premultiplied -> non-premultiplied
>> conversion when getting image data from canvas. It would still be possible
>> to do changes to the image data in JS, and then upload to WebGL. Or do you
>> see some issue with this alternative?
>> From: email@example.com <firstname.lastname@example.org> on
>> behalf of Ashley Gullen <email@example.com>
>> Sent: Thursday, November 5, 2015 5:18 PM
>> To: Helmut Emmelmann
>> Cc: firstname.lastname@example.org
>> Subject: Re: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and
>> UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2
>> On 5 November 2015 at 13:50, Helmut Emmelmann <email@example.com> wrote:
>>> > Lastly, these are slow paths, and as such are performance foot-guns,
>>> > even if we can (and do) warn when users use this functionality.
>>> On the other hand performance of texImage2D is very important,
>>> since it sometimes on slow devices and a large canvas takes longer than a
>>> frame and so causes dropped frames.
>> This can be mitigated by uploading in chunks with texSubImage2D, possibly
>> scheduled with something like requestIdleCallback. This only spreads out the
>> call across frames, and doesn't really make it async (which would be great
>> to have). I'm not sure if this impacts the question of supporting these
>> unpack options though, it sounds like it's harder for implementers to
>> support the sub-rectangle cases.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: