Re: [whatwg] WebGL and ImageBitmaps

On Tue, May 13, 2014 at 6:59 PM, K. Gadd <kg@luminance.org> wrote:

> On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> > Can you give an explicit example where browsers are having different
> > behavior when using drawImage?
>
> I thought I was pretty clear about this... colorspace conversion and
> alpha conversion happen here depending on the user's display
> configuration, the color profile of the source image, and what browser
> you're using. I've observed differences between Firefox and Chrome
> here, along with different behavior on OS X (presumably due to their
> different implementation of color profiles).
>
> In this case 'different' means 'loading & drawing an image to a canvas
> gives different results via getImageData'.
>
> On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> > Would this be solved with Greg's proposal for flags on ImageBitmap:
> >
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-June/251541.html
>
> I believe so. I think I was on record when he first posted that I
> consider the alpha and colorspace flags he described as adequate.
> FlipY is considerably less important to me, but I can see how people
> might want it (honestly, reversing the order of scanlines is a very
> cheap operation; you can do it in the sampling stage of your shader,
> and actually *have* to in OpenGL because of their coordinate system
> when you're doing render-to-texture.)
>
> On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> >> Very specifically here, by 'known color space' i just mean that the
> >> color space of the image is exposed to the end user. I don't think we
> >> can possibly pick a standard color space to always use; the options
> >> are 'this machine's current color space' and 'the color space of the
> >> input bitmap'. In many cases the color space of the input bitmap is
> >> effectively 'no color space', and game developers feed the raw rgba to
> >> the GPU. It's important to support that use case without degrading the
> >> image data.
> >
> >
> > Is that not the case today?
>
> It is very explicitly not the case, which is why we are discussing it.
> It is not currently possible to do lossless manipulation of PNG images
> in a web browser using canvas. The issues I described where you get
> different results from getImageData are a part of that.
>
> On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> > Safari never created a temporary image and I recently updated Firefox so
> it
> > matches Safari.
> > Both Safari, IE and Firefox will now sample outside of the drawImage
> region.
> > Chrome does not but they will fix that at some point.
>
> This is incorrect. A quick google search for 'webkit drawimage source
> rectangle temporary' reveals such, in a post to this list.
>
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/080583.html
> My statement to this effect was based on my (imperfect) memory of that
> post. 'CGImage' (to me) says Safari since it's an Apple API, and the
> post mentions Safari.


I made a codepen that showed the issue: http://codepen.io/adobe/pen/jIzbv
Firefox was not matching the behavior on mac because it created a
intermediate image. I fixed that in
https://bugzilla.mozilla.org/show_bug.cgi?id=987292

I agree that the code you linked to exists in WebKit but they add padding
so it samples outside the source again.

Received on Thursday, 15 May 2014 02:46:38 UTC