Re: Canvas in FX

On 11/23/2010 3:53 PM, Tab Atkins Jr. wrote:
> On Tue, Nov 23, 2010 at 3:30 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> On 11/23/2010 3:04 PM, Tab Atkins Jr. wrote:
>>> On Mon, Nov 22, 2010 at 4:04 PM, Charles Pritchard<chuck@jumis.com>
>>>   wrote:Hello FX list.
>>>> WebKit introduced getCSSCanvasContext quite some time ago:
>>>> http://webkit.org/blog/176/css-canvas-drawing/
>> ...
>>>> This is intended strictly for CSSCanvas, even though I'm using the
>>>> HTMLCanvas tag:
>>>>
>>>> <svg><g style="scale(1.5, 1.5)"><canvas></canvas></g></svg>
>> ...
>>>> I realize this is my first post on the list, and I haven't fully
>>>> explained
>>>> the use case. But I thought I'd start somewhere.
>>>>
>>>> The canvas backing store is a bitmap. That's how it works. That backing
>>>> store size could be dynamically increased and decreased, to best match
>>>> the
>>>> css resolution of its containing group.
>>> Apologies, but I don't understand whatsoever what you're trying to do
>>> here.  I followed the thread where you originally talked with roc, but
>>> I can't understand how you got from there to here, or even what "here"
>>> is.
>>>
>>> Could you try to explain what you're trying to achieve in a different way?
>> It's certainly my fault; I've got a solution in search of a problem.
>>
>> I'm trying to develop the concept of the "CSS Canvas" opposed to the HTML
>> Canvas, as I feel that exploring possible "CSS Canvas" semantics, is a
>> necessary step in bringing canvas functionality into SVG.
>> Beyond that, my thoughts and ideas are not well formed (though they are
>> informed).
>>
>> Lets consider canvas a paint server (instead of an element), as it makes
>> good sense within the context of CSS+SVG.
>>
>> When using a gradient as a paint server, implementations manage the
>> composition of that gradient, it doesn't create a small bitmap and then
>> scale it up -- it manages the fill to match the resolution/size of the
>> container. Regardless of scale/zoom, I should see a nice gradient.
>>
>> I'd like to something like this to happen when a CSS Canvas context is used
>> as a paint server.
>> "fillRect + createLinearGradient", for instance, would be as well managed as
>> "linearGradient" / css gradients.
>>
>> Does that make sense/help? I'm happy to provide more examples.
>
> Okay, so boiled down, your idea seems to be that you want to be able
> to use canvas as a paint server?  Sure, that seems reasonable.  That's
> already being addressed in two different ways - Moz has the
> -moz-element() function which lets you use an element in the DOM
> (which could be a<canvas>) as an image, while Webkit has
> -webkit-canvas() which hooks into a special canvas that doesn't live
> in the DOM.
>
> Both of these seem like good ideas.  I'm actively editing the CSS
> Image Values spec, and I'm actually adding element() to the spec
> *right now*.  I've been thinking about a canvas() function, and think
> it may be a good idea as well.
>
> Are there specific issues surrounding these two functions that you
> think need to be addressed?
Resolution and animation hooks [transitions].

There's a difference between using -element to make a dynamic background 
(or otherwise), and using it to fill a 'vector' element. We can use 
existing functions, with the existing canvas element, but I think it'd 
be wise to consider the "CSS Context" as an automated alternative.

This is basically what I'm thinking of, as the typical case:

// with a css transition applied to the canvas/parentNode on width changes.
var increaseBy = 2;
parentNode.style.width *= increaseBy; ctx.canvas.style.width *= increaseBy;
ontransitionend = function() {
  ctx.width = parseInt(parentNode.style.width);
  ctx.scale(increaseBy,increaseBy);
  myDrawCommands();
}

There are all sorts of tricky-techniques that could be used within that 
transition duration to make it more aesthetically pleasing. For 
instance, hooking into transitionstart instead of end, would mean that 
the image is not progressively blurrier during the transformation animation.

Things get confusion/complex, if the canvas is assigned as a paint 
server to multiple elements having different sizes.

For example: if the same paint server is assigned to a 20x20 area, and 
to a 1000x1000 area, it'd be faster [CPU cycles] to render to two 
different backing stores, than to size-down the 1000x1000 bitmap.

Another issue, if we are toying with the bitmap backing, is considering 
ImageData/CanvasPixelArray performance. Because we're talking about the 
realm of SVG, generally, the user should be using SVG FE, and not ImageData.

That's an outline of my understanding of implementation issues, in 
trying to keep the canvas as crisp and clear as the rest of the elements.

-Charles

Received on Wednesday, 24 November 2010 00:12:47 UTC