On Fri, 10 Jul 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
I don't see why the imagedata API isn't suitable for that. It's not
like if you're painting that on the canvas you'll want to leave the
last row or column unaffected. You'll want to clear it or some such,
in practice.
I
On Fri, 12 Jun 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
2) The description of putImageData says it Paints the data from the
given ImageData object onto the canvas. It may be worth
specifying that this uses the SOURCE operator, though this is
clear later on when
Ian Hickson wrote:
For another example, consider an algorithm that wants to reduce the size of
the image by 1px horizontally (e.g. content-aware image resizing as demoed
using canvas at
http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/).
If we're shrinking
On Fri, 10 Jul 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
For another example, consider an algorithm that wants to reduce the
size of the image by 1px horizontally (e.g. content-aware image
resizing as demoed using canvas at
Ian Hickson wrote:
I don't see why the imagedata API isn't suitable for that. It's not like
if you're painting that on the canvas you'll want to leave the last row or
column unaffected. You'll want to clear it or some such, in practice.
I believe in this case the page actually wants to create
On Sat, Jun 13, 2009 at 6:39 AM, Ian Hickson i...@hixie.ch wrote:
The long and short of this is that if we solve this problem today, the
solution will be abused as much as the current API, and we'll have to
introduce yet another solution when high-res backing stores are common. So
instead I'm
On Sat, 13 Jun 2009, Robert O'Callahan wrote:
On Sat, Jun 13, 2009 at 6:39 AM, Ian Hickson i...@hixie.ch wrote:
The long and short of this is that if we solve this problem today, the
solution will be abused as much as the current API, and we'll have to
introduce yet another solution when
On Sat, Jun 13, 2009 at 6:57 PM, Ian Hickson i...@hixie.ch wrote:
There's no practical difference as far as I can tell between hoping that
we can reuse the API, and then finding we can't, and introducing a second
API for high-res screens; and just giving up now and saying that it's a
low-res
Boris Zbarsky wrote:
It's not that hard, it's an extra four or five lines of code to fill
in multiple pixels in a square (two nested for-loops and an expression
or two to work out what the limit is). Compared to the maths such code
would be doing anyway, this is trivial stuff.
The hard part
On Mon, 1 Jun 2009, Boris Zbarsky wrote:
I still think that we need a better I have some externally-derived
pixel data I'd like to just stick in this canvas API here. fillRect()
has terrible performance characteristics (as has been brought up many
times before), and the current imagedata
Ian Hickson wrote:
2) The description of putImageData says it Paints the data from the
given ImageData object onto the canvas. It may be worth
specifying that this uses the SOURCE operator, though this is
clear later on when defining what the method _really_ does.
That's the
Ian Hickson wrote:
On Mon, 1 Jun 2009, Boris Zbarsky wrote:
I still think that we need a better I have some externally-derived
pixel data I'd like to just stick in this canvas API here. fillRect()
has terrible performance characteristics (as has been brought up many
times before), and the
On May 31, 2009, at 6:55 PM, Boris Zbarsky wrote:
3) It's not clear to me why imagedata actually exposes device
pixels,
nor is it clear to me how this is supposed to work if the same
document is being rendered to multiple devices. Is a UA allowed
to have a higher internal
On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote:
Here are a couple of relevant threads:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html
Then there was a discussion on #whatwg more
On Mon, Jun 1, 2009 at 7:13 PM, Maciej Stachowiak m...@apple.com wrote:
On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote:
Here are a couple of relevant threads:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html
Maciej Stachowiak wrote:
In some environments, a CSS pixel may be more than one device pixel.
Yes, I'm well aware.
In this case, getImageData followed by putImageData will lose resolution.
Right. I did mention that in my reply to Oliver.
It seems that there are two significantly
Boris Zbarsky wrote:
The other use case is doing createImageData, followed by filling in the
pixels, followed by putImageData.
I just saw the example in the spec that does just this, but bases the
values it puts in on numbers it gets out of getImageData. For that case
you would of course
I was just looking at the spec text on getImageData/putImageData, and I
had a few comments. Of the three, #3 is the most important one:
1) It may be worth noting that if the canvas backing store is stored
as premultiplied rgba, then getImageData right after a putImageData
may well not
Worse yet, the current setup means that a script that tries
createImageData, fill in the pixels, and then paint it to the
canvas, needs to fill different numbers of pixels depending on the
output device. I fully expect script authors to get this very very
wrong, since it's such
Oliver Hunt wrote:
Worse yet, the current setup means that a script that tries
createImageData, fill in the pixels, and then paint it to the
canvas, needs to fill different numbers of pixels depending on the
output device. I fully expect script authors to get this very very
On Mon, Jun 1, 2009 at 3:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Oliver Hunt wrote:
Worse yet, the current setup means that a script that tries
createImageData, fill in the pixels, and then paint it to the
canvas, needs to fill different numbers of pixels depending on the
21 matches
Mail list logo
