On Fri, 04 Sep 2009 02:44:25 +0200, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote:
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you
On Mon, 31 Aug 2009, Philip J�genstedt wrote:
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Aug 2009, Philip J�genstedt wrote:
As far as I can see there's no good reason why createImageData
should take a float as input rather than unsigned long.
On Thu, 03 Sep 2009 13:54:03 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 31 Aug 2009, Philip J�genstedt wrote:
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Aug 2009, Philip J�genstedt wrote:
As far as I can see there's no good reason why
Philip Jägenstedt wrote:
I wasn't involved then, but I can only presume that there was no
perceived benefit of high-DPI ImageData since you can get high-quality
rendering just as well with techniques that don't rely on the canvas
being higher resolution than the display device.
To be clear,
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's implementation has always worked with high dpi backing stores
and follows the spec accordingly.
--Oliver
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's implementation has always worked with high dpi backing
On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote:
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's
On Mon, 24 Aug 2009, Philip Jägenstedt wrote:
As far as I can see there's no good reason why createImageData should
take a float as input rather than unsigned long. Having it as float
creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while
(10.1, 10.1) gives a 10x10 or 11x11
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Aug 2009, Philip Jägenstedt wrote:
As far as I can see there's no good reason why createImageData should
take a float as input rather than unsigned long. Having it as float
creates the odd situation where (0.1,
On Mon, Aug 31, 2009 at 1:55 AM, Philip Jägenstedt phil...@opera.comwrote:
I get the impression this has all been discussed before.
It has.
Still, it seems unlikely that any browser will ever be able to switch to
anything but a 1:1 CSS pixel:device pixel ratio, as that would break all
Philip Jägenstedt wrote:
In any event, judging by existing implementations, the behavior of
createImageData(w, h) isn't as clear as it needs to be:
Firefox:
Just to be clear, the Firefox code for this predates the spec text.
I would assume so does Webkit's.
Once we're actually trying
On Mon, Aug 31, 2009 at 11:06 PM, Anne van Kesteren ann...@opera.comwrote:
Once we get huge screens and lots of processing power people can just blow
up the canvas grid and then scale it down with CSS. Works just as well and
makes the data more portable.
I think we can do better than that.
As far as I can see there's no good reason why createImageData should take
a float as input rather than unsigned long. Having it as float creates the
odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1)
gives a 10x10 or 11x11 depening on if you ceil or round the input (not
13 matches
Mail list logo
