On Feb 11, 2008 2:57 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
On Feb 10, 2008, at 5:44 PM, Robert O'Callahan wrote:
On Feb 11, 2008 1:05 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
i was thinking having a style property, say, canvas-dpi: auto|device or
something, where the default auto
On Feb 11, 2008, at 12:33 AM, Robert O'Callahan wrote:
...
I was assuming no-one supported getImageData/putImageData during
those 5 years. Then there would be no content using it that would be
broken.
Alas there are already sites depending on it, so we're doomed
On Feb 11, 2008, at
On Jan 26, 2008 11:57 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
Another thing that we need is some way to determine what the device
pixel-css pixel ratio is. Currently there's isn't even a real way to
tell that it's 1:1 -- you would have do do a fillRect(width-1,
height-1, 1, 1),; then
On Feb 10, 2008, at 12:41 AM, Robert O'Callahan wrote:
On Jan 26, 2008 11:57 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
Another thing that we need is some way to determine what the device
pixel-css pixel ratio is. Currently there's isn't even a real way to
tell that it's 1:1 -- you would have
On Feb 10, 2008 10:07 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
That said, basically what you're saying is that canvas should not support
hidpi. At all. There is no need to request the dpi of a canvas, but (and
here's the critical bit) you can't have get/putImageData work at a different
On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote:
On Feb 10, 2008 10:07 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
That said, basically what you're saying is that canvas should not
support hidpi. At all. There is no need to request the dpi of a
canvas, but (and here's the critical bit)
On Sun, 10 Feb 2008, Robert O'Callahan wrote:
So for ImageData, how about making the image data array have, by
default, one pixel value per canvas coordinate unit? If we really need
to expose a higher-resolution underlying buffer, then add an API to get
the device-pixel per
On Feb 11, 2008 11:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
If we have one API, high-res only:
People who use it correctly:
get good results both today and tomorrow.
People who use it wrongly:
get good results today.
will get cropped or visibly wrong results tomorrow.
On Feb 10, 2008, at 2:53 PM, Robert O'Callahan wrote:
On Feb 11, 2008 11:37 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote:
On Feb 10, 2008 10:07 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
That said, basically what you're saying is that canvas
On Feb 10, 2008, at 3:08 PM, Robert O'Callahan wrote:
On Feb 11, 2008 11:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
If we have one API, high-res only:
People who use it correctly:
get good results both today and tomorrow.
People who use it wrongly:
get good results today.
On Feb 11, 2008 1:05 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
i was thinking having a style property, say, canvas-dpi: auto|device or
something, where the default auto value automagically does the evil
downsampling the moment a data routine is used, and device would result in
the right thing.
If, 5 years from now, most Web developers have 200dpi screens so
browsers are using at least a 2:1 ratio for their canvas backing
stores, then putImageData and getImageData could be safely
introduced with the current spec, because an assumption that device
pixels are the same as canvas
On Feb 10, 2008, at 5:44 PM, Robert O'Callahan wrote:
On Feb 11, 2008 1:05 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
i was thinking having a style property, say, canvas-dpi: auto|device
or something, where the default auto value automagically does the
evil downsampling the moment a data
On Feb 11, 2008 12:51 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
and the cost of sub-/super-sampling removes the whole speed thing
that the API was originally added for.
Not so sure about this. Script manipulation of pixel data probably isn't
going to be faster than native, probably
Dnia 25-01-2008, Pt o godzinie 15:05 -0800, Oliver Hunt pisze:
Ah true I had forgotten that, however this still fails for non-
integral ratios :-/
Non-integral ratios can be approximated by a series of rational ones.
Chris
So I came across this wonderful piece of javascript:
http://jsmsxdemo.googlepages.com/jsmsx.html
If present it uses putImageData (and getImageData to get the ImageData
object, which isn't required by html5 now -- and i think hixie was
look at doing some more work with ImageData).
With the
On Jan 25, 2008, at 6:56 AM, Oliver Hunt wrote:
With the current model for putImageData there is no way for them to
specify a dirty rect, which means their only option is to update the
entire display -- they have to copy the entire buffer.
snip
Anyway, i was thinking we would just need
On Fri, 25 Jan 2008 23:57:56 +0100, Oliver Hunt [EMAIL PROTECTED] wrote:
Another thing that we need is some way to determine what the device
pixel-css pixel ratio is. Currently there's isn't even a real way to
tell that it's 1:1 -- you would have do do a fillRect(width-1, height-1,
1, 1),;
On Fri, 25 Jan 2008 23:56:28 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
getImageData/putImageData will definitely cause problems for high-DPI
displays in the future that are driven with a scale factor where CSS
pixels are not device pixels. The question is whether it's better for
On Jan 25, 2008, at 2:30 PM, Anne van Kesteren wrote:
On Fri, 25 Jan 2008 21:00:41 +0100, Oliver Hunt [EMAIL PROTECTED]
wrote:
[...]
I had a question as I still think ImageData should be simplified.
Are you planning to support high resolution ImageData objects? As
specified ImageData
Another thing that we need is some way to determine what the device
pixel-css pixel ratio is. Currently there's isn't even a real way to
tell that it's 1:1 -- you would have do do a fillRect(width-1,
height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see
if they match.
On Jan 25, 2008, at 6:53 AM, Adam Roben wrote:
On Jan 25, 2008, at 6:56 AM, Oliver Hunt wrote:
With the current model for putImageData there is no way for them to
specify a dirty rect, which means their only option is to update
the entire display -- they have to copy the entire buffer.
Yet more commentary:
I noticed that the behaviour is undefined if putImagedata is provided
an ImageData object on which the width, height, or data member is a
getter that throws an exception.
A quick check shows that FFX3 throws a type mismatch -- eg. acts as
though the field was invalid.
On 23/01/2008, Oliver Hunt [EMAIL PROTECTED] wrote:
It would be great if putImageData
could take a source region, in addition to the destination. One of
the primary reasons for using get/putImageData is to allow JS to
rapidly blit data to the screen, however without an ability to blit
only a
On 23/01/2008, at 5:44 AM, Philip Taylor wrote:
On 23/01/2008, Oliver Hunt [EMAIL PROTECTED] wrote:
It would be great if putImageData
could take a source region, in addition to the destination. One of
the primary reasons for using get/putImageData is to allow JS to
rapidly blit data to the
25 matches
Mail list logo
