On Thu, Apr 16, 2015 at 7:07 AM, Justin Novosad 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, which I document
On Wed, Apr 15, 2015 at 1:46 PM, Dean Jackson wrote:
>
> On 16 Apr 2015, at 6:42 am, Elliott Sprehn 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 wou
> On 16 Apr 2015, at 6:42 am, Elliott Sprehn 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 from firing fr
On Wed, Apr 15, 2015 at 12:07 PM, Justin Novosad 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, which I documen
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 y
On Thu, Jul 3, 2014 at 3:03 AM, Justin Novosad wrote:
> On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan
> wrote:
> This behavior seems sound at first glance, but because that arithmetic may
> >> induce a change to the intrinsic aspect ratio due to rounding, step 3)
> may
> >> not jump out of
On Fri, Jun 27, 2014 at 6:42 PM, Robert O'Callahan
wrote:
> On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad wrote:
>
>> Example of a problematic renderedsizechange event listener:
>>
>> canvas.width = Math.floor(canvas.renderedPixelWidth * myPixelScale);
>> canvas.height = Math.floor(canvas.rend
On Sat, Jun 28, 2014 at 3:41 AM, Justin Novosad 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 anyone would a
On Thu, Jun 26, 2014 at 6:25 PM, Robert O'Callahan
wrote:
> On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad 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 mod
On Fri, Jun 27, 2014 at 2:00 AM, Justin Novosad 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 renderedPixelWidth/Height returns th
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 conte
On Thu, Jun 26, 2014 at 10:13 AM, Robert O'Callahan
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 similar for
> height.
>
On Thu, Jun 26, 2014 at 10:10 AM, Robert O'Callahan
wrote:
> On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad 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 f
On Thu, Jun 26, 2014 at 2:49 AM, Justin Novosad 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 a
> way that d
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 lot
On Wed, Jun 25, 2014 at 3:30 PM, Rik Cabanier 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
> renderedsizec
On Mon, Jun 23, 2014 at 6:06 PM, Robert O'Callahan
wrote:
> On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan
> wrote:
>
>> I'll do that now.
>>
>
> Done.
> http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
>
The wiki states:
Add a new event renderedsizechange to HTMLCanvasElement. This ev
On Mon, Jun 23, 2014 at 6:06 PM, Robert O'Callahan wrote:
> On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan
> wrote:
>>
>> I'll do that now.
>
>
> Done.
> http://wiki.whatwg.org/wiki/CanvasRenderedPixelSize
Fantastic. Thanks Rob. That looks great. Filed crbug.com/388532 about
implementing th
On Tue, Jun 24, 2014 at 12:27 PM, Robert O'Callahan
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.r"t sS?o Whhei csha iids teo
On Tue, Jun 24, 2014 at 11:44 AM, Kenneth Russell 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 proceed? W
On Mon, Jun 23, 2014 at 4:25 PM, Robert O'Callahan wrote:
> On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell 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 different types of CSS boxes
On Tue, Jun 24, 2014 at 8:54 AM, Kenneth Russell 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 different types of CSS boxes (content, padding, border, margin)
> -- will it be obvious to web
On Thu, Jun 19, 2014 at 4:20 PM, Robert O'Callahan wrote:
> On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell 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.
>
> Geck
On Thu, Jun 19, 2014 at 7:03 PM, Robert O'Callahan
wrote:
> On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad 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 a
On Fri, Jun 20, 2014 at 6:06 AM, Kenneth Russell 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 to device
p
On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad 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
> the "preferre
On Fri, Jun 20, 2014 at 2:54 AM, Stephen White
wrote:
> I assume that the size change event would fire:
>
>- on browser page zoom
>- on pinch-zoom
>- when a CSS animation (e.g., scale) changes the canvas size in CSS
>pixels
>
> For browsers that implement the latter two off the ma
+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 non-cancelab
> On 20 Jun 2014, at 12:54 am, Stephen White wrote:
>
> On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan
> 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
On Thu, Jun 19, 2014 at 7:54 AM, Stephen White wrote:
> On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan
> 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
On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan
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
> invariant that the
On Thu, Jun 19, 2014 at 12:01 AM, Robert O'Callahan
wrote:
> On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan
> wrote:
>
>> On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad wrote:
>>
>>> I am currently trying an experimental approach where canvases that are
>>> drawn to, but never read from (
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 w
On Thu, Jun 19, 2014 at 11:52 AM, Robert O'Callahan
wrote:
> On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad 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
On Wed, Jun 18, 2014 at 8:30 AM, Justin Novosad 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.
> And I think th
On Thu, Jun 19, 2014 at 3:30 AM, Justin Novosad 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 must be a cli
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 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 ar
[Resurrecting old thread]
On Tue, Sep 10, 2013 at 12:00 PM, 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
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' });
>
On Fri, Sep 27, 2013 at 5:51 PM, Ian Hickson 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 why
On Mon, 9 Sep 2013, Rik Cabanier wrote:
> On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson 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 end u
On Thu, Sep 12, 2013 at 10:42 AM, Ian Hickson wrote:
> On Thu, 12 Sep 2013, Robert O'Callahan wrote:
> > On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson wrote:
> > > On Wed, 11 Sep 2013, Robert O'Callahan wrote:
> > > > Pinch-zoom is hard because we don't want to trigger reflows or other
> > > > e
On Thu, 12 Sep 2013, Robert O'Callahan wrote:
> On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson 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
On 11 Sep 2013, at 3:20 am, Robert O'Callahan wrote:
> On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier 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:
> https://groups.
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson 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 fundamen
On Wed, 11 Sep 2013, Rik Cabanier wrote:
> On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson 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
On Wed, Sep 11, 2013 at 11:24 AM, Ian Hickson 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 fund
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 1:20 AM, Robert O'Callahan 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
>> > > canv
On Tue, Sep 10, 2013 at 1:26 PM, Rik Cabanier 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:
>
> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RyUSi
On Tue, Sep 10, 2013 at 10:46 PM, Tab Atkins Jr. wrote:
> 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 devicePixelRatio on man
On Tue, Sep 10, 2013 at 6:24 PM, Glenn Maynard 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 display
On Mon, Sep 9, 2013 at 7:31 PM, Ian Hickson 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, we could
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 talk
On Wed, 11 Sep 2013, Dean Jackson wrote:
> On 11 Sep 2013, at 12:14 am, Stephen White
> 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 should do is also
On Tue, 10 Sep 2013 21:22:51 +0100, 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
If you merge the two, then an unsuspecting developer might think that
the user has zoo
On 11 Sep 2013, at 12:14 am, Stephen White wrote:
> now that some browsers are including browser zoom (page zoom) in
> window.devicePixelRatio
Ouch. Who is doing this and why?
Dean
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 fai
On Tue, Sep 10, 2013 at 12:45 PM, Dean Jackson wrote:
>
> On 11 Sep 2013, at 5:32 am, Ian Hickson wrote:
>
> > On Wed, 11 Sep 2013, Dean Jackson wrote:
> >> On 11 Sep 2013, at 12:14 am, Stephen White
> >> wrote:
> >>>
> >>> now that some browsers are including browser zoom (page zoom) in
> >>>
On 11 Sep 2013, at 6:13 am, Ian Hickson wrote:
> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 5:32 am, Ian Hickson wrote:
>>> On Wed, 11 Sep 2013, Dean Jackson wrote:
On 11 Sep 2013, at 12:14 am, Stephen White
wrote:
>
> now that some browsers are includin
On Wed, 11 Sep 2013, Dean Jackson wrote:
> On 11 Sep 2013, at 5:32 am, Ian Hickson wrote:
> > On Wed, 11 Sep 2013, Dean Jackson wrote:
> >> On 11 Sep 2013, at 12:14 am, Stephen White
> >> wrote:
> >>>
> >>> now that some browsers are including browser zoom (page zoom) in
> >>> window.devicePix
On 11 Sep 2013, at 5:32 am, Ian Hickson wrote:
> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 12:14 am, Stephen White
>> wrote:
>>>
>>> now that some browsers are including browser zoom (page zoom) in
>>> window.devicePixelRatio
>>
>> Ouch. Who is doing this and why?
>
>
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
There is another closely related issue that's been discussed before: adding
a redraw callback to 2d canvas. In the past we discussed this for solving
the problem of recoverring from a gpu context loss, but it seems there may
be better reasons to consider adding a redraw callback such as freeing
me
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 we'
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 th
On Mon, Sep 9, 2013 at 5:00 PM, Ian Hickson 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, Dean Jackson 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 end up with canvases
> > with four canvas pixels per CSS
On 10 Sep 2013, at 10:00 am, Ian Hickson 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 dr
On Mon, Sep 9, 2013 at 5:00 PM, 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
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 since the HD methods are going away from the one
>
73 matches
Mail list logo
