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: firstname.lastname@example.org <email@example.com> on behalf of Ashley Gullen <firstname.lastname@example.org>
Sent: Thursday, November 5, 2015 5:18 PM
To: Helmut Emmelmann
Subject: Re: [Public WebGL] Proposal: Ignore UNPACK_FLIP_Y and UNPACK_PREMULTIPLY_ALPHA for ArrayBufferViews in WebGL 2On 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.