On Fri, 11 Feb 2011, Glenn Maynard wrote:
On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 29 Dec 2010, Glenn Maynard wrote:
I hit this problem in a UI I worked on. It rendered into a canvas
the size of the window, which can be zoomed and scrolled around.
On Thu, May 12, 2011 at 11:34 PM, Ian Hickson i...@hixie.ch wrote:
No, ImageData exposes the underlying data, not the data in CSS pixels.
I know. That's what I was responding to: having different backing store
dimensions and dimensions exposed by ImageData doesn't make sense.
If you mean
On Fri, 13 May 2011, Glenn Maynard wrote:
On Thu, May 12, 2011 at 11:34 PM, Ian Hickson i...@hixie.ch wrote:
No, ImageData exposes the underlying data, not the data in CSS pixels.
I know. That's what I was responding to: having different backing store
dimensions and dimensions exposed
On Fri, May 13, 2011 at 12:29 AM, Ian Hickson i...@hixie.ch wrote:
It's pretty much the entire point of that API. That's why it has separate
height/width information than the canvas. It has to be that way because
there's no guarantee that CSS pixels will map to device pixels -- and
that's not
On Fri, 13 May 2011, Glenn Maynard wrote:
On Fri, May 13, 2011 at 12:29 AM, Ian Hickson i...@hixie.ch wrote:
It's pretty much the entire point of that API. That's why it has
separate height/width information than the canvas. It has to be that
way because there's no guarantee that CSS
On Wed, 29 Dec 2010, Glenn Maynard wrote:
On Wed, Dec 29, 2010 at 7:38 PM, Ian Hickson i...@hixie.ch wrote:
Any UI that is based on being able to zoom content (e.g. maps is
another one) would presumably have in-page zoom separate from UA zoom,
but you'd still want to be able to change
On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 29 Dec 2010, Glenn Maynard wrote:
I hit this problem in a UI I worked on. It rendered into a canvas the
size of the window, which can be zoomed and scrolled around. At 100%
full page zoom this works well. At 120%
Regarding:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029557.html
My objections have been noted throughout the threads:
It's not possible to discover the scaling of CSS pixels to actual device
pixels, with the current standard.
Ian's response:
This is by design. You
On Fri, Dec 31, 2010 at 8:17 PM, Charles Pritchard ch...@jumis.com wrote:
Nor will it be addressed, as Mozilla has given firm notice, they've
intentionally obfuscated
the value (devicePixelRatio), in the scripting environment. I dislike seeing
that kind of behavior
in any software.
It
On Fri, 19 Nov 2010, Charles Pritchard wrote:
It's not possible to discover the scaling of CSS pixels to actual device
pixels, with the current standard.
This is by design. You shouldn't need to know the actual device pixel
depth, as far as I can tell. What's the use case?
On Sat, 20 Nov
On Wed, Dec 29, 2010 at 7:38 PM, Ian Hickson i...@hixie.ch wrote:
Any UI that is based on being able to zoom content (e.g. maps is another
one) would presumably have in-page zoom separate from UA zoom, but you'd
still want to be able to change the UA zoom (changing the CSS pixel size,
On 11/24/2010 10:23 AM, Boris Zbarsky wrote:
On 11/24/10 4:13 AM, Charles Pritchard wrote:
And, these aren't great lengths. It's about 6 lines of javascript.
Uh... That depends on how your drawing path is set up. If I understand
correctly what you're doing, you have to get the DPI ration
On 2010-12-18 18:58, Charles Pritchard wrote:
On 11/24/2010 10:23 AM, Boris Zbarsky wrote:
On 11/24/10 4:13 AM, Charles Pritchard wrote:
And, these aren't great lengths. It's about 6 lines of javascript.
Uh... That depends on how your drawing path is set up. If I understand
correctly what
On 12/14/2010 9:51 PM, Simon Fraser wrote:
On Dec 14, 2010, at 10:22 AM, Charles Pritchard wrote:
On 11/24/2010 1:12 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
On 11/21/2010 4:12 PM, Robert O'Callahan
On 11/24/2010 1:12 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
On 11/21/2010 4:12 PM, Robert O'Callahan wrote:
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard
ch...@jumis.com
Kevin,
I spoke with a rep on Google TV, as well as a Microsoft IE rep: neither
saw an active use-case for non-square pixels.
There are cases where width is stretched / squished, but they're always
handled by scaling the output image. Think of fancy window manager
effects, and of the ratio
On 11/24/2010 2:45 PM, Aryeh Gregor wrote:
On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchardch...@jumis.com wrote:
I greatly appreciate the value of standards, but I am at the same time, very
sensitive to the effects that centrally planned restrictions have on groups.
The aggregate effect is
Am 24.11.2010 um 23:59 schrieb Charles Pritchard:
There is evidence that it will enhance usability for programmers who use it
properly.
Focus.
-Charles
Do you mean functionality rather than usability? As I understand this, an
author of a web page has neither control of nor knowledge
On 11/21/2010 4:12 PM, Robert O'Callahan wrote:
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
Rob: Mobile deployments using dpiPixelRatio (as has been adopted
by Moz and Webkit) and target-DpiDensity work well on the mobile,
they
On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard ch...@jumis.com wrote:
window.dpiPixelRatio does not change.
Is it mozDpiPixelRatio ?
There is no such property.
Rob
--
Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great
On 11/24/2010 1:12 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 9:09 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
On 11/21/2010 4:12 PM, Robert O'Callahan wrote:
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard
ch...@jumis.com
Sorry about that, devicePixelRatio
On 11/24/2010 1:14 AM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 10:14 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
window.dpiPixelRatio does not change.
Is it mozDpiPixelRatio ?
There is no such property.
Rob
--
Now
https://bugzilla.mozilla.org/show_bug.cgi?id=486200
Come on Robert:
It needs to be chrome-only because I don't want Web authors to have
easy access
to information about screen pixels. They'll try to defeat our zooming or
size
things to screen pixels, which we don't want.
They defeat your
Charles Pritchard wrote:
TV use-cases seem like they'll become more prevalent, with Apple and Google
and their devices.
Apple TV doesn't have legacy connectors--only HDMI. A quick look at the specs
of Google TV devices suggests that Google TV devices are also HDMI-only.
The devices sold as
On 11/24/10 4:13 AM, Charles Pritchard wrote:
And, these aren't great lengths. It's about 6 lines of javascript.
Uh... That depends on how your drawing path is set up. If I understand
correctly what you're doing, you have to get the DPI ration (call it N),
change the canvas width/height by a
On 11/24/2010 10:23 AM, Boris Zbarsky wrote:
On 11/24/10 4:13 AM, Charles Pritchard wrote:
And, these aren't great lengths. It's about 6 lines of javascript.
Uh... That depends on how your drawing path is set up. If I understand
correctly what you're doing, you have to get the DPI ration
On 11/24/10 1:26 PM, Charles Pritchard wrote:
But the upshot is that people make mistakes. If you don't assume they
will, you come to grief.
Assuming they'll make mistakes is different than having zero faith in
their competence.
I have zero faith in across-the-board competence.
That is,
On 11/24/2010 10:56 AM, Boris Zbarsky wrote:
On 11/24/10 1:26 PM, Charles Pritchard wrote:
But the upshot is that people make mistakes. If you don't assume they
will, you come to grief.
Assuming they'll make mistakes is different than having zero faith in
their competence.
I have zero faith
On 2010/11/24 18:38 (GMT-0800) Charles Pritchard composed:
I've only asked that information be made available. The response from your group seems to
be you can't handle the truth!
As a non-UA developer spectating since the beginning of this thread, my take
on what you're asking for is it
On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchard ch...@jumis.com wrote:
I greatly appreciate the value of standards, but I am at the same time, very
sensitive to the effects that centrally planned restrictions have on groups.
The aggregate effect is one where tens of millions are harmed by
On 11/24/2010 2:45 PM, Aryeh Gregor wrote:
On Wed, Nov 24, 2010 at 4:38 PM, Charles Pritchardch...@jumis.com wrote:
I greatly appreciate the value of standards, but I am at the same time, very
sensitive to the effects that centrally planned restrictions have on groups.
The aggregate effect is
Most video displays have non-square pixels. Standard definition video
processing resolutions are 720 by 480 for NTSC and 720 by 576 for PAL though
both are 4 by 3 aspect ratio.
You can argue whether tv standards count as modern, but there are a lot out
there.
On 21 Nov 2010 16:56, Robert
On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks kevinma...@gmail.com wrote:
Well, if we care about doing video processing with Canvas, understanding
anamorphic pixels is needed.
You mean the aspect ratio of the video source? Sure, but here we're talking
about the output device.
Anyway, adding
On 11/23/10 5:06 PM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 1:53 PM, Kevin Marks kevinma...@gmail.com
mailto:kevinma...@gmail.com wrote:
Well, if we care about doing video processing with Canvas,
understanding anamorphic pixels is needed.
You mean the aspect ratio of the
Message: 1
Date: Mon, 22 Nov 2010 15:27:40 -0500
From: Boris Zbarskybzbar...@mit.edu
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Processing the zoom level - MS extensions to
window.screen
Message-ID:4cead23c.1000...@mit.edu
Content-Type: text/plain; charset=ISO-8859-1; format
On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard ch...@jumis.com wrote:
SVG is a document format. It is not reliably implemented. It's far more
expensive to implement SVG on a new environment than Canvas.
So? You don't have to implement it.
I can't do much for you here other than
On 11/23/10 9:30 PM, Charles Pritchard wrote:
Most uses of canvas involve keeping state-info around in order to redraw
the screen.
Quite a number do, yes. A number don't.
I'll challenge you on this one: I don't think there are a number of them
that don't.
We may just have a different idea
On 11/23/2010 6:46 PM, Robert O'Callahan wrote:
On Wed, Nov 24, 2010 at 3:30 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
SVG is a document format. It is not reliably implemented. It's
far more expensive to implement SVG on a new environment than Canvas.
So?
On 11/22/10 12:30 AM, Robert O'Callahan wrote:
On Mon, Nov 22, 2010 at 8:49 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
On 11/21/10 10:51 PM, Robert O'Callahan wrote:
On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard
ch...@jumis.com mailto:ch...@jumis.com
On 11/22/10 12:22 AM, Charles Pritchard wrote:
OpenGL has an immediate-mode which does not require a bitmap backend.
Sure. But if it's going to be resolution independent, then there needs
to be a retained mode somewhere in the stack, even if it's not exposed
to the original caller (e.g. you
On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
Most of the use cases for script access to the exact device pixel ratio that
I've heard boil down to interfere with the user's ability to zoom, which
is why I haven't been eager to make it easier.
Might there be
On Mon, Nov 22, 2010 at 10:07 AM, Aryeh Gregor
simetrical+...@gmail.comsimetrical%2b...@gmail.com
wrote:
On Sat, Nov 20, 2010 at 12:21 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
Most of the use cases for script access to the exact device pixel ratio
that
I've heard boil down to
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard ch...@jumis.com wrote:
Rob: Mobile deployments using dpiPixelRatio (as has been adopted by Moz and
Webkit) and target-DpiDensity work well on the mobile, they are not hooked
to zoom on the desktop,
It is in Firefox.
and they were not
On 11/21/10 4:12 PM, Robert O'Callahan wrote:
On Sun, Nov 21, 2010 at 9:59 AM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
Rob: Mobile deployments using dpiPixelRatio (as has been adopted
by Moz and Webkit) and target-DpiDensity work well on the mobile,
they are
On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard ch...@jumis.com wrote:
I would point out that the MS proposal has an independent X and Y scaling
mechanism.
Does anyone know of any modern displays which have different X and Y
resolution?
I believe that dpi ratio is simply set to 2 (or
On 11/21/10 4:56 PM, Robert O'Callahan wrote:
On Mon, Nov 22, 2010 at 1:40 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
I would point out that the MS proposal has an independent X and Y
scaling mechanism.
Does anyone know of any modern displays which have
On 11/21/10 6:30 PM, Boris Zbarsky wrote:
On 11/21/10 8:31 PM, Charles Pritchard wrote:
Canvas is an immediate mode rendering framework. I realize that it uses
a bitmap backend,
Isn't that more or less a requirement for immediate mode? After
all, the whole issue is that when resolution
On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard ch...@jumis.com wrote:
I've a deep and detailed understanding of the SVG, HTML, DOM and CSS specs.
Just out of interest, why aren't you using SVG?
I understand the need to make canvas backing store pixels map to device
pixels when possible.
On 11/21/10 10:51 PM, Robert O'Callahan wrote:
On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
I've a deep and detailed understanding of the SVG, HTML, DOM and
CSS specs.
Just out of interest, why aren't you using SVG?
Many thanks for
On Fri, Nov 19, 2010 at 9:21 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
Most of the use cases for script access to the exact device pixel ratio
that I've heard boil down to interfere with the user's ability to zoom,
which is why I haven't been eager to make it easier.
To be clear,
On Nov 20, 2010, at 7:46 AM, Ojan Vafai wrote:
On Fri, Nov 19, 2010 at 9:21 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
Most of the use cases for script access to the exact device pixel ratio that
I've heard boil down to interfere with the user's ability to zoom, which is
why I
On Sat, Nov 20, 2010 at 9:49 AM, Simon Fraser s...@me.com wrote:
On Nov 20, 2010, at 7:46 AM, Ojan Vafai wrote:
To be clear, chrome.tabs.getZoomPercentage is a Chrome extension API. Having
extensions that can mess with zoom seems like a legit use-case. But I agree,
I can't think of good
This response is from the digest: I'm glad to see activity here.
As I can't figure out how to hit reply in thread, I'll take some editorial
discretion here and just summarize it, so we can make a decision on the
use case.
Ojan calls for: good use-cases for the general web,
Boris implies that
On 11/20/10 3:59 PM, Charles Pritchard wrote:
This response is from the digest: I'm glad to see activity here.
Canvas is supposed to be resolution independent,
No, it's not. Vector images are supposed to be resolution independent.
Canvas is very explicitly a _bitmap_. It's not a vector
It's not possible to discover the scaling of CSS pixels to actual device
pixels, with the current standard.
There are three non-standard ways to access them, from what I can see.
Mozilla:
On 11/19/10 3:04 PM, Charles Pritchard wrote:
Mozilla:
window.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindowUtils).screenPixelsPerCSSPixel
Note that if you try to do this in a web page, it will throw. That
entire interface is
On Sat, Nov 20, 2010 at 10:42 AM, Boris Zbarsky bzbar...@mit.edu wrote:
We (Mozilla) have no plans to expose screen pixels to untrusted content at
the moment, more or less as a policy decision.
We actually do support the -moz-device-pixel-ratio CSS media query. There
are legitimate use cases
57 matches
Mail list logo
