[whatwg] Processing the zoom level - MS extensions to window.screen

On 11/21/10 10:51 PM, Robert O'Callahan wrote:
> On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard <chuck at jumis.com 
> <mailto:chuck at 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 the SVG Filter Effect CSS extension.
I'd like to see that catch on with other vendors.

Implementations of SVG are uneven and/or slow:

Example: SVG Filter Effect + with an animated rotate in FF 3 (excuse me 
if this is dated)
was quite slow, though the SVG FE implementation is faster than 
CanvasPixelArray.
It's also tricky, getting SVG FE turned on (for me anyway), with the 
xhtml mime requirements.

I don't fault anyone in this. SVG is a large, complex spec. A lot of 
work goes into SVG clients.
With Canvas, we have fine control over performance and memory usage. 
Much of those options
have analogs in SVG [like freezing composition between layers], and when 
we do target an SVG-strict profile,
we'll exploit those options.

For both performance and compatibility reasons, we've had to write low 
level code anyway.
Actual display calls (be they SVG-able or not) are a relatively small 
part of our app.

I'm currently focused on interchangeability of our HTML and Canvas profiles.
Many SVG features are available via CSS now: paint servers and gradients,
rounded rectangles, some text effects.

Because of that, we're focused on HTML.
SVG FE is definitely in our code base as a rendering option.
We store our iconography in SVG, and some basic glyphs.
We use canvas to render the glyphs, and we pre-render our iconography 
into png.

> I understand the need to make canvas backing store pixels map to 
> device pixels when possible. Suppose that, on clearing the canvas 
> (e.g. by setting the width or height attribute), the browser 
> automatically set the canvas backing store density so that canvas 
> backing store pixels map to device pixels (taking into account the 
> current zoom settings). Suppose further that browsers fired the 
> 'resize' event when they zoom in a way that changes the window size 
> (as they should, even if they currently don't). Then on 'resize' you 
> could clear your canvas and redraw it, and automatically get a canvas 
> backing store with the right resolution with no further code changes. 
> Would that address your use case?
I appreciate your understanding, and your brainstorming.

We currently use downsampled images within our application, and this 
proposal would override them We use them where filter effects are live, 
and are too expensive for the host to process quickly. Sampling is also 
useful as a memory management technique. On a resource constrained 
device, for whatever reason, it can make sense to draw the canvas at a 
smaller size, even though upscaling is noticable.

With a complex gui / canvas drawing, redrawing the image may take some 
time. During zoom events, I can use a setTimeout to wait for the browser 
to settle before redrawing at higher resolution. CSS automates 
everything for me. It works wonderfully.

Generally, with Canvas, things should not be automated. It's the CSS 
that's automated.
Think of CSS as sending GPU instructions, and Canvas as simply updating 
a texture within the GPU.

AFAIK, it is standard in practice, to send a resize event, as the page 
layout does change (innerWidth changes). I'd like to see this mentioned 
in a standards document. I think we all agree that 'zoom' should send a 
resize event, and currently does.

For ease of use, it's as easy in canvas as it is in CSS to handle scaling:

myDrawFunc = function() {
  ctx.save();
  ctx.scale(dpiScale,dpiScale);
  runMyRepainterCommands();
  ctx.restore();
}
window.onresize = myDrawFunc;

I was able to support resolution scaling on a complex application with 
less than an hour of work. It took me longer to test compatibility 
between browsers,
for the hacks I used to try and get the DPI Scale values.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101121/c183335d/attachment.htm>

Received on Sunday, 21 November 2010 23:49:45 UTC