724447 - Provide an API for accessing compressed image data

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

+++ This bug was initially created as a clone of Bug #724419 +++

The reporter of the original bug has an addon that wants to access the compressed image data.  Currently he is using a synchronous XHR that tries to hit the cache.

I think instead we should add an API to imgIContainer that allows accessing the uncompressed data (at least for RasterImages).  Jeff, Joe, Bobby, thoughts?

Comment 1

[Bobby Holley (:bholley)]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #0)
> I think instead we should add an API to imgIContainer that allows accessing
> the uncompressed data (at least for RasterImages).  Jeff, Joe, Bobby,
> thoughts?

This is currently possible via canvas+drawImage+readPixels. Is there a compelling need for a more streamlined approach?

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Bobby Holley (:bholley) from comment #1)
> (In reply to Kyle Huey [:khuey] ([e-mail]) from comment #0)
> > I think instead we should add an API to imgIContainer that allows accessing
> > the uncompressed data (at least for RasterImages).  Jeff, Joe, Bobby,
> > thoughts?
> 
> This is currently possible via canvas+drawImage+readPixels. Is there a
> compelling need for a more streamlined approach?

He wants the compressed data, not the uncompressed data.

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

And yes, I realize I mixed those up in comment 0 ;-)

Comment 4

[Bobby Holley (:bholley)]

(In reply to Bobby Holley (:bholley) from comment #1)
> This is currently possible via canvas+drawImage+readPixels. Is there a
> compelling need for a more streamlined approach?

Hm. I'm a bit concerned about that, because that uncompressed data may or may not exist (depending on whether we're storing source data or not). The existence of this data is an internal decision for Imagelib, and we might run into trouble if people start relying on it and we subsequently change our heuristics.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Joe and I discussed this a little while ago, and decided that we should get the XHR approach working well before we try to make a new API for accessing that data.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

What do you mean by the XHR approach?  He wants to get the data that's already been downloaded, not make another roundtrip to the server.  Using sync XHR to hit the cache is a horribly hacky way to do that.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #6)
> What do you mean by the XHR approach?  He wants to get the data that's
> already been downloaded, not make another roundtrip to the server.  Using
> sync XHR to hit the cache is a horribly hacky way to do that.

It's true that it's hacky, but it's existing api that's supported by other browsers and it doesn't add any additional constraints on the imagelib implementation.

Comment 8

[Boris Zbarsky [:bzbarsky]]

The context is an extension.  It wants to make sure that it doesn't hit the server.  It's already setting flags on the XHR channel that force it to read from cache only, so it's not like it's worried about other browsers.

Fwiw, wontfixing this bug is fine by me; we just shouldn't pretend that there is an alternate way to get the data.  The answer may be that we simply don't have the compressed data anywhere at all.