[whatwg] whatwg Digest, Vol 80, Issue 31

> Date: Sat, 20 Nov 2010 21:57:02 -0500
> From: Boris Zbarsky<bzbarsky at MIT.EDU>
> To: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Processing the zoom level - MS extensions	to
> 	window.screen
> Message-ID:<4CE88A7E.3020205 at mit.edu>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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 image.
>    
Canvas is an immediate mode rendering framework. I realize that it uses 
a bitmap backend,
but the drawing itself works very much like vector imaging. The scene 
graph is built in
the scripting environment instead of an ML file.

>   >  When a user zooms in, I need to be able to reprint my fillText
>    
>> to match their resolution.
>>      
> This is a valid use case if using canvas is the right requirement,
> though it really feels like you're using the wrong tool here; if you
> want resolution independence you should be using SVG, which is designed
> precisely to accomplish that.
>    
I've heard this before, and I'm afraid that it's a stuck-issue I'll 
never unstick.
Canvas is a low level API, SVG is a serialized format of a scene graph. 
They're not the same thing.

You may implement an SVG rendering engine in Canvas, you may use some 
other scene graph.

I've been through this discussion with several people, and I really do 
lack the perspective to
understand the hang-up on "SVG" vs Canvas. One is a rendering API, one 
is a serialized file format.
They're two different classes.
> That said, this seems like a general quality-of-implementation issue,
> right?  Expecting the page to rerender the entire canvas on any zoom
> operation doesn't seem reasonable....  A UA could handle this by
> supersampling the canvas, for example (and in the past we've considered
> doing that for Firefox, actually).
>    
While Apple has certainly worked in supersampling, it's completely 
unnecessary.
I don't see why expecting a page to re-render is unreasonable. That's 
exactly what pages do
right now. In most implementations, Canvas is tied to the same 
rasterization engine as HTML.

I've demonstrated a rich application with zooming quality equivalent to 
the HTML rendering.
There's a reason why they are equivalent: they're using the same logic, 
they're using the same
raster libraries. They are in a very physical sense, the same.

Stated succinctly: It is entirely reasonable to re-render canvas when an 
"onresize" event is received,
it's a standard practice. There's no reason for the UA to handle it any 
differently than it does now
(scaling the CSS pixels). This is something to be left up to the 
implementer.

>> Boris, Rob: As an accessibility use case, this is quite important.
>> Please let me know if there are objections.
>>      
> I don't think it's reasonable to demand resolution independence from
> what is designed to be a bitmap format.  We really do have better tools
> for them; using them instead seems more appropriate than grafting
> poor-man's resolution independence onto canvas.
>    
PNG is a bitmap format. Canvas is a drawing API. It's not poor-man's 
resolution independence:
it's a reasonable, standards based implementation. It exists now, it 
works fine, and I am notably
frustrated by your responses. They are not grounded in an appreciation 
for my use cases nor
the evidence I have to provide.

When I say: please expose additional screen metrics, you respond: You're 
doing it wrong,
it's poor, and we tried to do it for you, but it didn't work out.

I mean.. come on.

My evidence is essentially nullified when you make broad statements 
about how there are
better tools and better formats. I don't doubt your good intentions 
here, but I am suggesting
that you've made an error in judgement.


-Charles

Received on Sunday, 21 November 2010 17:31:22 UTC