On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <caban...@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 <caban...@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 <caban...@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 <caban...@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.
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.


Reply via email to