W3C home > Mailing lists > Public > www-svg@w3.org > February 2012

Re: canvas in SVG (was: Re: SVG 2 Requirements: next phase)

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 23 Feb 2012 15:27:42 -0800
Message-ID: <CAGN7qDCUb39Bvdj+e27VGTBr9=y-vDQW2c9UwQXpCr_OvfX=8w@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: public-svg-wg@w3.org, www-svg <www-svg@w3.org>
That's great.
If implementers believe it's easy to get to the canvas bitmap in all cases,
we should try to get it into SVG as soon as possible.
It would give SVG the ability to mimic Flash's BitmapData class which has
many use cases.


On Thu, Feb 23, 2012 at 3:05 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> At your request, I've copied this over to www-svg.  Responses, please
> go to www-svg only.
> What's the difference between www-svg and public-svg-wg?  Why do we
> even have two public groups?
> On Thu, Feb 23, 2012 at 11:49 AM, Rik Cabanier <cabanier@adobe.com> wrote:
> > Do you have an example where it works with a 3d context?
> >
> > I completely agree that SVG doesn't need to solve the details here and
> can just follow HTML.
> > I think we should be aware of potential technical issues that would make
> this hard to implement.
> Unfortunately, I don't have an example.  Mozilla, who supports
> -moz-element(), apparently hates the graphics card on my work computer
> and wont' initialize a webgl context for me, so I can't test.  Chrome,
> who supports -webkit-canvas(), never plumbed the webgl context through
> the getCSSCanvasContext() code, so it doesn't work.
> However, I just talked to one of our canvas people (James Robinson)
> and he said that webgl and HW-accler 2d canvas are about the same in
> terms of difficulty applying to this case, and the latter works fine
> in -webkit-canvas() (which is roughly the same as -moz-element() for
> this case).  So, no, it won't be a problem.
> ~TJ
Received on Thursday, 23 February 2012 23:28:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:27 UTC