<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 11/22/10 12:30 AM, Robert O'Callahan wrote:
<blockquote
cite="mid:AANLkTi=hDW6Hm0PSJeu0roxVGzms9U=KiqWwSEbvKkoE@mail.gmail.com"
type="cite">On Mon, Nov 22, 2010 at 8:49 PM, Charles Pritchard <span
dir="ltr"><<a moz-do-not-send="true" href="mailto:chuck@jumis.com">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;">
<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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
I wasn't able to "freeze" the composition of the SVG layer. Upon
rotation, the SVG layer re-filters the image,<br>
it re-runs the filter effect on each rotation. With canvas, I simply
re-draw the filtered image<br>
into the rotation.<br>
<br>
I don't mean to get caught up in particular platform quirks. It's been
a few months since I've<br>
addressed SVG ones. SVG FE afaik, was only in FF 3.6 w/ strict reqs.<br>
<br>
We target several browsers; so regardless of the merits of SVG in FF
3.6, we still try to support<br>
FF 3.0 and other legacy browsers and non-gecko browsers.<br>
<br>
Simply, Canvas is less expensive to implement, and I'm sure far fewer
LOC than SVG,<br>
so it's uptake was reasonably quick, and adding it to a new platform is
reasonably quick.<br>
<br>
<blockquote
cite="mid:AANLkTi=hDW6Hm0PSJeu0roxVGzms9U=KiqWwSEbvKkoE@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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>
</div>
</div>
</blockquote>
My attention is still on exposing metrics so I can repaint to the
device resolution, fully within the existing standard. I don't want to
change a thing about CSS/Canvas; just looking for some data to be
available in the DOM.<br>
<br>
It's a DOM deficiency in relation to the canvas tag.<br>
Google Books demonstrates a use case apart from Canvas. They don't need
to override the browser's zoom. They do provide their own icon. If the
browser did provide<br>
information, about zoom, they could send a higher resolution image to
the browser for that portion.<br>
<br>
Here's a good, short, example of an SVG/WebGL+Canvas+HTML+CSS profile:<br>
[canvas style="filter: url(#myPixelFilter); scale(.5,.5)"]<br>
Everything is doing exactly what it should.<br>
<br>
My only active proposal for the canvas spec is exposing a baseline
property in TextMetrics. textBaseline is insufficient on its own.<br>
<blockquote
cite="mid:AANLkTi=hDW6Hm0PSJeu0roxVGzms9U=KiqWwSEbvKkoE@mail.gmail.com"
type="cite">
<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;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<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>
</div>
</blockquote>
</div>
</blockquote>
...<br>
<blockquote
cite="mid:AANLkTi=hDW6Hm0PSJeu0roxVGzms9U=KiqWwSEbvKkoE@mail.gmail.com"
type="cite">
<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;">
<div bgcolor="#ffffff" text="#000000">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>
</blockquote>
<br>
It would be a non-standard extension to canvas that I would have to
write additional code to support. It would create more complexity for
the other browsers to add to their implementations. It may alter
ImageData or otherwise require more overhead for CanvasPixelArray
manipulation, slowing things down.<br>
<br>
I would have to check my backing size before redrawing, to gain control
again. It would effectively require more data lookups and a storage
table (in script) so I know which elements have which backing
resolution. We do have cases where we want our backing store to be
different than the native resolution; these are typically related to
rendering speed/responsiveness. Some use cases are related to memory
management.<br>
<br>
Your proposal would 'fix' existing apps written in canvas, ones at
least that weren't designed with pixel ratio in mind. But I don't think
it's necessary, and it would create more work for apps that do want to
use pixel ratio data, as well as suggesting more work to canvas
implementers in other browsers. It does make some sense as a CSS
extension, which would be turned off by default. Having a toggle, and
having it off by default would address all of my concerns about the
proposal.<br>
<br>
The method you've proposed is something that should be brought up to
the SVG working group in relation to future SVG + Canvas
interoperability. They're looking to extend the SVG standard, to bring
in lessons from Canvas. Within the context of an SVG scene graph and a
new draft of SVG, I think a dynamic backing store would work
wonderfully. SVG has many additional use cases not related to browser
zoom, and I think it'd be the best place to try out the technique.
Another area to try it out might be with getCSSCanvasContext, as it has
different semantics than getContext, and it seems like a great fit:
<a class="moz-txt-link-freetext" href="http://webkit.org/blog/176/css-canvas-drawing/">http://webkit.org/blog/176/css-canvas-drawing/</a><br>
<br>
I do feel like this proposal is a new idea, it's a good one. It's a bit
more work on browser vendors, to address zoom, than the short-term work
of making sure that they actually expose css pixel metrics to the
scripting environment. Like many css options, I'm sure it'd be easier
on some code bases than others.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>