W3C home > Mailing lists > Public > public-fx@w3.org > October to December 2010

Re: Canvas in FX

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Nov 2010 15:53:40 -0800
Message-ID: <AANLkTinNiS0WK1YSBfdKnYe9k_f7A-tV9EpZ3j6r5YUS@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: public-fx@w3.org, robert@ocallahan.org
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?

~TJ
Received on Tuesday, 23 November 2010 23:54:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 November 2010 23:54:39 GMT