On Mon, Nov 22, 2010 at 8:49 PM, Charles Pritchard <span dir="ltr"><<a href="mailto:chuck@jumis.com">chuck@jumis.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">



  

<div><div class="im">
On 11/21/10 10:51 PM, Robert O'Callahan wrote:
<blockquote type="cite">On Mon, Nov 22, 2010 at 6:22 PM, Charles Pritchard <span dir="ltr"><<a href="mailto:chuck@jumis.com" target="_blank">chuck@jumis.com</a>></span>
wrote:<br>
  <div class="gmail_quote">
  <blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">I've
a deep and detailed understanding of the SVG, HTML, DOM and CSS specs.<br>
  </blockquote>
  <div><br>
Just out of interest, why aren't you using SVG?<br>
  </div>
  </div>
</blockquote></div>
Many thanks for the SVG Filter Effect CSS extension.<br>
I'd like to see that catch on with other vendors.<br>
<br>
Implementations of SVG are uneven and/or slow:<br>
<br>
Example: SVG Filter Effect + with an animated rotate in FF 3 (excuse me
if this is dated)<br>
was quite slow, though the SVG FE implementation is faster than
CanvasPixelArray.<br>
It's also tricky, getting SVG FE turned on (for me anyway), with the
xhtml mime requirements.<br></div></blockquote><div><br>That doesn't really explain why you're using canvas, if SVG is faster than canvas for your effect.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
For both performance and compatibility reasons, we've had to write low
level code anyway.<br>
Actual display calls (be they SVG-able or not) are a relatively small
part of our app.<br><br></div></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#ffffff" text="#000000">
I'm currently focused on interchangeability of our HTML and Canvas
profiles.<br>
Many SVG features are available via CSS now: paint servers and
gradients,<br>
rounded rectangles, some text effects.<br>
<br>
Because of that, we're focused on HTML.<br>
SVG FE is definitely in our code base as a rendering option.<br>
We store our iconography in SVG, and some basic glyphs.<br>
We use canvas to render the glyphs, and we pre-render our iconography
into png.</div></blockquote><div><br>It's important to separate the issues that are fixable implementation limitations from those issues that are fundamental to the design of Web standards. There is no point in adding new platform features to work around implementation limitations; we get a simpler platform if implementors just fix the existing features.<br>
<br>So, for example, I wouldn't want to add canvas features to address use-cases for which SVG would work well if it was a bit better implemented.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"><div class="im"><br>
<blockquote type="cite">
  <div class="gmail_quote">
  <div>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?<br>
  </div>
  </div>
</blockquote></div>
I appreciate your understanding, and your brainstorming.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Generally, with Canvas, things should not be automated. It's the CSS
that's automated.<br>
Think of CSS as sending GPU instructions, and Canvas as simply updating
a texture within the GPU.<br>
<br>
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.<br>
<br>
For ease of use, it's as easy in canvas as it is in CSS to handle
scaling:<br>
<br>
myDrawFunc = function() {<br>
 ctx.save();<br>
 ctx.scale(dpiScale,dpiScale);<br>
 runMyRepainterCommands();<br>
 ctx.restore();<br>
}<br>
window.onresize = myDrawFunc;<br>
<br>
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,<br>
for the hacks I used to try and get the DPI Scale values.<br></div></blockquote><div> </div></div>It sounds to me like the approach I described would work for you.<br><br clear="all">Rob<br>-- <br>"Now the Bereans were of more noble character than the 
Thessalonians, for they received the message with great eagerness and 
examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]<br>