Re: [whatwg] WebGL and ImageBitmaps

On Mon, May 12, 2014 at 3:19 AM, K. Gadd <kg@luminance.org> wrote:

> On Fri, May 9, 2014 at 12:02 PM, Ian Hickson <ian@hixie.ch> wrote:
> > I'm assuming you're referring to the case where if you try to draw a
> > subpart of an image and for some reason it has to be sampled (e.g. you're
> > drawing it larger than the source), the anti-aliasing is optimised for
> > tiling and so you get "leakage" from the next sprite over.
> >
> > If so, the solution is just to separate the sprites by a pixel of
> > transparent black, no?
>
> This is the traditional solution for scenarios where you are sampling
> from a filtered texture in 3d. However, it only works if you never
> scale images, which is actually not the case in many game scenarios.
>

That's only an issue when sampling without premultiplication, right?

I had to refresh my memory on this:

https://zewt.org/~glenn/test-premultiplied-scaling/

The first image is using WebGL to blit unpremultiplied.  The second is
WebGL blitting premultiplied.  The last is 2d canvas.  (We're talking about
canvas here, of course, but WebGL makes it easier to test the different
behavior.)  This blits a red rectangle surrounded by transparent space on
top of a red canvas.  The black square is there so I can tell that it's
actually drawing something.

The first one gives a seam around the transparent area, as the white pixels
(which are completely transparent in the image) are sampled into the
visible part.  I think this is the problem we're talking about.  The second
gives no seam, and the Canvas one gives no seam, indicating that it's a
premultiplied blit.  I don't know if that's specified, but the behavior is
the same in Chrome and FF.


On Tue, May 13, 2014 at 8: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'.
>

That's a description, not an explicit example.  An example would be a URL
demonstrating the issue.

The effects of color profiles should never be visible to script--they
should be applied when the canvas is drawn to the screen, not when the
image is decoded or the canvas is manipulated.  That seems hard to
implement, though, if you're blitting images to a canvas that all have
different color profiles.  It's probably better to ignore color profiles
for canvas entirely than to expose the user's monitor configuration like
this...

-- 
Glenn Maynard

Received on Wednesday, 14 May 2014 23:27:51 UTC