On Thu, Apr 16, 2015 at 7:07 AM, Justin Novosad ju...@google.com wrote:
In the interest of moving forward with this, I began an experimental
implementation of the renderedPixelWidth/Height propsal (
https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink. I ran
into
some issues,
On Wed, Apr 15, 2015 at 12:07 PM, Justin Novosad ju...@google.com wrote:
In the interest of moving forward with this, I began an experimental
implementation of the renderedPixelWidth/Height propsal (
https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink. I ran
into
some issues,
On 16 Apr 2015, at 6:42 am, Elliott Sprehn espr...@chromium.org wrote:
3. Accessing rendered pixel size is layout-inducing. To avoid layout
thrashing, we should consider making this an asynchronous getter (e.g.
asyncGetBoundignClientRect). This would also prevent renderedsizechanged
events
In the interest of moving forward with this, I began an experimental
implementation of the renderedPixelWidth/Height propsal (
https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize) in Blink. I ran into
some issues, which I documented in the issues section of the proposal. I
would like to draw
On Wed, Apr 15, 2015 at 1:46 PM, Dean Jackson d...@apple.com wrote:
On 16 Apr 2015, at 6:42 am, Elliott Sprehn espr...@chromium.org wrote:
3. Accessing rendered pixel size is layout-inducing. To avoid layout
thrashing, we should consider making this an asynchronous getter (e.g.
On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad ju...@google.com wrote:
Example of a problematic renderedsizechange event listener:
canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale);
On Thu, Jul 3, 2014 at 3:03 AM, Justin Novosad ju...@google.com wrote:
On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
This behavior seems sound at first glance, but because that arithmetic may
induce a change to the intrinsic aspect ratio due to rounding,
On Thu, Jun 26, 2014 at 6:25 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad ju...@google.com wrote:
Hadn't thought of that. object-fit seems smells dangerous. I think we may
need to define explicit behaviors for renderedPixelWidth/Height for
On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad ju...@google.com wrote:
Example of a problematic renderedsizechange event listener:
canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale);
canvas.height = Math.floor(canvas.renderedPixelHeight * myPixelScale);
I don't know why
Hadn't thought of that. object-fit seems smells dangerous. I think we may
need to define explicit behaviors for renderedPixelWidth/Height for the
different object fit modes.
For example, with 'object-fit: contains', will the renderedPixelWidth/Height
be computed in a way to fill the element's
On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad ju...@google.com wrote:
Hadn't thought of that. object-fit seems smells dangerous. I think we may
need to define explicit behaviors for renderedPixelWidth/Height for the
different object fit modes.
I don't think so. Given
I was wondering if there is anything we can do with this feature to prevent
web apps from creating layout feedback loops. What I mean is that if the
event listener for renderedsizechange changes the layout of the page in a
way that does not preserve renderedPixelWidth/Height, we can get into a
On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad ju...@google.com wrote:
I was wondering if there is anything we can do with this feature to prevent
web apps from creating layout feedback loops. What I mean is that if the
event listener for renderedsizechange changes the layout of the page in
On Thu, Jun 26, 2014 at 10:10 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad ju...@google.com wrote:
I was wondering if there is anything we can do with this feature to
prevent
web apps from creating layout feedback loops. What I mean is
On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
To clarify, I think a version of option #1 would be the best way to go.
renderedPixelWidth would return the current canvas buffer width when the
canvas element's CSS specified value for 'width' is 'auto', and
On Mon, Jun 23, 2014 at 6:06 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I'll do that now.
Done.
http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
Fantastic. Thanks Rob. That looks great. Filed
On Mon, Jun 23, 2014 at 6:06 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I'll do that now.
Done.
http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
The wiki states:
Add a new event renderedsizechange
On Wed, Jun 25, 2014 at 3:30 PM, Rik Cabanier caban...@gmail.com wrote:
Add a new event renderedsizechange to HTMLCanvasElement. This event does
not bubble and is not cancelable. Whenever the value that would be returned
by renderedPixelWidth orrenderedPixelHeight changes, queue a task to fire
On Thu, Jun 19, 2014 at 4:20 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell k...@google.com wrote:
It is a little unfortunate that a canvas-specific solution is needed.
Is it known whether document.getBoxQuads solves this problem in
Firefox?
On Mon, Jun 23, 2014 at 4:25 PM, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell k...@google.com wrote:
It's hard to predict. A more general API would be better than a
canvas-specific one, assuming it solves the problem. getBoxQuads can
return
On Tue, Jun 24, 2014 at 11:44 AM, Kenneth Russell k...@google.com wrote:
If there's no concern about potential duplicated functionality then
let's add the attributes to the canvas element. They'll be easier for
developers to understand and easier to verify as obviously correct.
How should we
On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I'll do that now.
Done.
http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
Rob
--
Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o
On Thu, Jun 19, 2014 at 7:03 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad ju...@google.com wrote:
+1 from me too. But I have one concern in terms of future proofing,
because
I would like to keep the door open for auto-resizing as a
On 19/06/2014 00:30, Justin Novosad wrote:
My main point is, there is potentially significant progress in terms
of HD canvas rendering that can be achieved without any changes to the
spec (other than perhaps an opt-in flag). If it works out well without
an explicit opt-in, legacy websites will
On Thu, Jun 19, 2014 at 12:01 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad ju...@google.com wrote:
I am currently trying an experimental approach where
On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I think I'd rather not take control of canvas resizing away from
applications, even opt-in. That leads to complexity such as extra API for
slaving other canvases. I also think we'd be better off sticking to the
On Thu, Jun 19, 2014 at 7:54 AM, Stephen White senorbla...@chromium.org wrote:
On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I think I'd rather not take control of canvas resizing away from
applications, even opt-in. That leads to complexity such as extra API
On 20 Jun 2014, at 12:54 am, Stephen White senorbla...@chromium.org wrote:
On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
I think I'd rather not take control of canvas resizing away from
applications, even opt-in. That leads to complexity such as extra
+1 from me too. But I have one concern in terms of future proofing, because
I would like to keep the door open for auto-resizing as a possible future
improvement. In an eventual auto-resize proposal, we will want to make
the preferredsizechange
event cancelable. If we make the event
On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad ju...@google.com wrote:
+1 from me too. But I have one concern in terms of future proofing, because
I would like to keep the door open for auto-resizing as a possible future
improvement. In an eventual auto-resize proposal, we will want to make
On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell k...@google.com wrote:
It is a little unfortunate that a canvas-specific solution is needed.
Is it known whether document.getBoxQuads solves this problem in
Firefox?
It doesn't.
Gecko (and I assume other engines) typically snaps CSS box edges
In the previous incarnation of High density canvases (i.e. getImageDataHD
and friends), we worked under the assumption that it was okay to have a
backing store with a pixel density that is higher than CSS pixel density.
And I think that was perfectly acceptable.
If I recall correctly, the feature
On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad ju...@google.com wrote:
I am currently trying an experimental approach where canvases that are
drawn to, but never read from (no toDataURL or getImageData calls) have
their contents stored as a command buffer, rather than a pixel buffer.
There
On Wed, Jun 18, 2014 at 8:30 AM, Justin Novosad ju...@google.com wrote:
In the previous incarnation of High density canvases (i.e. getImageDataHD
and friends), we worked under the assumption that it was okay to have a
backing store with a pixel density that is higher than CSS pixel density.
On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad ju...@google.com wrote:
I am currently trying an experimental approach where canvases that are
drawn to, but never read from (no toDataURL or getImageData calls)
On 13/06/2014 12:42, Robert O'Callahan wrote:
Here's an alternative proposal which I think is a bit simpler and more
flexible:
Expose two new DOM attributes on HTMLCanvasElement:
readonly attribute long preferredWidth;
readonly attribute long preferredHeight;
These attributes are the
[Resurrecting old thread]
On Tue, Sep 10, 2013 at 12:00 PM, Ian Hickson i...@hixie.ch wrote:
It would be nice to fix these all at once, and I think we can, by
introducing a configuration option on getContext(), in the style of WebGL:
getContext('2d', { density: 'autosize' });
This would
On Tue, 10 Sep 2013, Ian Hickson wrote:
On Tue, 10 Sep 2013, Ian Hickson wrote:
It would be nice to fix these all at once, and I think we can, by
introducing a configuration option on getContext(), in the style of
WebGL:
getContext('2d', { density: 'autosize' });
This
On Fri, Sep 27, 2013 at 5:51 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 10 Sep 2013, Stephen White wrote:
For posterity, here were our objections to the original high-DPI canvas
spec:
- It doesn't scale well to non-integer devicePixelRatios
Can you elaborate on this? I don't see
On Mon, 9 Sep 2013, Rik Cabanier wrote:
On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson i...@hixie.ch wrote:
So my understanding is that the reason this feature failed is that
there's existing content that assumes a 1:1 ratio, and having an
automatic high-density mode was making some pages
On Thu, Sep 12, 2013 at 10:42 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 12 Sep 2013, Robert O'Callahan wrote:
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Robert O'Callahan wrote:
Pinch-zoom is hard because we don't want to trigger reflows
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Robert O'Callahan wrote:
Pinch-zoom is hard because we don't want to trigger reflows or other
expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for
now.
Unless I'm missing something
On 11 Sep 2013, at 3:20 am, Robert O'Callahan rob...@ocallahan.org wrote:
On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier caban...@gmail.com wrote:
There's a thread on www-style:
http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html
It's been in firefox for a while and blink is going
On Thu, 12 Sep 2013, Robert O'Callahan wrote:
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Robert O'Callahan wrote:
Pinch-zoom is hard because we don't want to trigger reflows or other
expensive behavior on pinch-zoom. I'd leave pinch-zoom out
On Tue, Sep 10, 2013 at 10:46 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
High-end laptops have high-dpi screens (the Pixel I'm using right now
has one), and they're slowly spreading down the price scale.
On Mac there are Retinas of course, and on Windows Firefox defaults to a
non-1.0
On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier caban...@gmail.com wrote:
There's a thread on www-style:
http://lists.w3.org/Archives/Public/www-style/2012Nov/0144.html
It's been in firefox for a while and blink is going to ship it soon:
On Wed, Sep 11, 2013 at 1:20 AM, Robert O'Callahan rob...@ocallahan.org wrote:
Actually what I really think we should do is also change the
window.devicePixelRatio for pinch zoom. Combined with the suggestions
for
canvas, that would allow (as Rik pointed out on IRC) for high-quality
On Wed, 11 Sep 2013, Robert O'Callahan wrote:
Pinch-zoom is hard because we don't want to trigger reflows or other
expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for
now.
Unless I'm missing something fundamental, changing the pixel density
doesn't cause a layout, it's
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Robert O'Callahan wrote:
Pinch-zoom is hard because we don't want to trigger reflows or other
expensive behavior on pinch-zoom. I'd leave pinch-zoom out of it for
now.
Unless I'm missing something
On Wed, 11 Sep 2013, Rik Cabanier wrote:
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Robert O'Callahan wrote:
Pinch-zoom is hard because we don't want to trigger reflows or other
expensive behavior on pinch-zoom. I'd leave pinch-zoom out of
For posterity, here were our objections to the original high-DPI canvas
spec:
- The API feels like a short-term hack to automagically do something
that the developer may or may not want done (e.g., if the game/app was
tuned for particular resolution, or for pixel-exact rendering) that
On 9/10/13 2:55 PM, Dean Jackson wrote:
Ouch. Who is doing this and why?
Any browser in which zoom changes the size of a CSS pixel, and because
that's the definition of devicePixelRatio?
-Boris
On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org
wrote:
now that some browsers are including browser zoom (page zoom) in
window.devicePixelRatio
Ouch. Who is doing
On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org
wrote:
now that some browsers are including browser zoom (page zoom) in
On 11 Sep 2013, at 6:13 am, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org
wrote:
now that
On Tue, Sep 10, 2013 at 12:45 PM, Dean Jackson d...@apple.com wrote:
On 11 Sep 2013, at 5:32 am, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org
wrote:
now that some browsers are including
On Wed, 11 Sep 2013, Dean Jackson wrote:
I think there are two separate things a developer might want:
- the number of actual pixels that correspond to 1 CSS px without zoom
- the page zoom
Why? Exposing page zoom separately from device density seems like a
fundamental abstraction
On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org wrote:
now that some browsers are including browser zoom (page zoom) in
window.devicePixelRatio
Ouch. Who is doing this and why?
Dean
On Tue, 10 Sep 2013 21:22:51 +0100, Dean Jackson d...@apple.com wrote:
I think there are two separate things a developer might want:
- the number of actual pixels that correspond to 1 CSS px without zoom
- the page zoom
If you merge the two, then an unsuspecting developer might think that
On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 12:14 am, Stephen White senorbla...@chromium.org
wrote:
now that some browsers are including browser zoom (page zoom) in
window.devicePixelRatio
Ouch. Who is doing this and why?
Why ouch?
Actually what I really think we
On 9/10/13 4:13 PM, Ian Hickson wrote:
I guess we'll just have to treat devicePixelRatio as legacy and introduce
a new value that's the real device:pixel ratio, then.
I would be interested in some data on what different UAs do with
devicePixelRatio...
-Boris
On 9/10/13 4:22 PM, Dean Jackson wrote:
I think there are two separate things a developer might want:
- the number of actual pixels that correspond to 1 CSS px without zoom
What are the use cases for this, as opposed to number of actual pixels
that correspond to 1 CSS px?
And are you
On Mon, Sep 9, 2013 at 7:31 PM, Ian Hickson i...@hixie.ch wrote:
Right, resetting the context would definitely be part of the deal. This
mode would be specifically defined as a mode where you had to listen to
onresize or your canvas would almost certainly get cleared sooner or
later. In fact,
On Tue, Sep 10, 2013 at 6:24 PM, Glenn Maynard gl...@zewt.org wrote:
Yeah, my suggestion, if we do this, would be to not do it until high
density displays are even more widely available than now. This is mostly a
convenience and performance-improving API, not a critical feature add.
High-DPI
On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson i...@hixie.ch wrote:
It would be nice to fix these all at once, and I think we can, by
introducing a configuration option on getContext(), in the style of WebGL:
getContext('2d', { density: 'autosize' });
This would trigger the following
On 10 Sep 2013, at 10:00 am, Ian Hickson i...@hixie.ch wrote:
On Wed, 17 Jul 2013, Rik Cabanier wrote:
Ian wrote:
The density aspect of this might be pointless, given the failure of
getImageDataHD(); if we're dropping that one, I'll drop this one at
the same time.
Yes, please drop it
On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 17 Jul 2013, Rik Cabanier wrote:
Ian wrote:
The density aspect of this might be pointless, given the failure of
getImageDataHD(); if we're dropping that one, I'll drop this one at
the same time.
Yes,
On Tue, 10 Sep 2013, Ian Hickson wrote:
It would be nice to fix these all at once, and I think we can, by
introducing a configuration option on getContext(), in the style of
WebGL:
getContext('2d', { density: 'autosize' });
This would trigger the following behaviour: When the
68 matches
Mail list logo
