RE: HTML 5 Canvas spec [3D and SVG]

Indeed, you are prescient about this Donald--there is interesting and
frustrating stuff out there ahead.
 
When we go beyond 2D to 3D, that brings up a welter of other mechanisms
for getting graphics stuff on somebody's display.  Here in Boeing of
course we are deeply involved in massive capabilities like CGM/WebCGM
(not me personally).  Obviously, way beyond what SVG ever intended to
address, in scope, size, depth.  This computer / web graphics arena such
a vast field, it's hard to narrow down opportunities to choose paths and
work on them.  
 
Seems like there is some distinguishing matrix of 2/3D graphics
characteristics, you almost need a Edward Tufte-like mind mapof them
floating out there in space, where  you could regard their various
aspects and figure out where the world is going, then flip it around and
look at it using a different lens.  Some of the axes might be things
like simple vs. complex, declarative vs. imperative, past-present-future
(progressions or versioning), open vs. proprietary, platforms it runs
on, and so forth.  One might observe the progression thru VML, to SVG,
to future versions of it, or the rise of integrated RIA graphics
thingies like FLEX/Flash, as pieces of this larger picture.  As it is,
it's kind of hard to get oriented to the many things that are on tap.
 
Apologies if I am rambling, but one might set out to articulate some
sort of positioning of SVG as it is now, or where it's going, in
relation to those other things, that *could* help someone get engaged.
It's a very significant and useful standard (IMHO)!
 
David.A.Porter@Boeing.com 
Distributed Server Integration, GG-GG-5581, homepage
http://grp-cno-dst-svr.web.boeing.com/ 
Boeing Information Technology, Bellevue Washington USA 
* phone 253-223-4732, other contact options at
http://card.web.boeing.com/WebCard.cfm?id=113185 
Server Inventory links:
http://distributedserver.web.boeing.com/serverinventory/ServerInventoryL
inks.htm 


________________________________

From: Donald Doherty [mailto:donald.doherty@brainstage.com] 
Sent: Wednesday, September 10, 2008 11:37 AM
To: Dailey, David P.
Cc: public-svg-ig@w3.org
Subject: Re: HTML 5 Canvas spec [3D and SVG]


David, 

Thank you for jumping in on this topic. I'm only jumping in now because
I'm so behind in my email...

HTML 5 Canvas brings up an SVG frustration for us. That is, 3D displays!

SVG in my opinion becomes very interesting in the context of Web
applications (as apposed to Web pages...I mean applications like Google
spreadsheets, docs, etc.). However, applications - and especially those
in life sciences and medicine - often demand 3D graphics.

A standard means for displaying high-quality 3D images would go a long
way towards making SVG irresistible!

Don

Donald Doherty, Ph.D.
Founder and Chief Science Officer
Brainstage, Inc.
www.brainstage.com
donald.doherty@brainstage.com
412-683-1410


On Sep 3, 2008, at 12:16 PM, Dailey, David P. wrote:


	Hi David:

	

	David Porter wrote:

	

	".[...]Is it a threat or complement
	to one's SVG work?  [...] 'A 3D Exploration of the HTML Canvas
Element Greg Travis, DevX.com' "
	 
	 

	I thought someone else might make a stab at this but given that
they didn't I guess I will.  Maybe I'll say something wrong just on
purpose to see if we can persuade lurkers to join some of the
conversations.

	

	When I found out about <canvas> I thought it was someone's
attempt to sabotage SVG. The Apple folks who promoted it tried to
convince others that it was something entirely different (using lots of
fancy jargon to make their point). I remained very skeptical.

	

	Then someone (like maybe Anne from Opera) wrote something in the
HTML5 discussions that basically said - hey mellow out - they both do
useful stuff. So I have mellowed a bit and concede the point. <canvas>
is likely to be a really fast way of blittiing pixels onto the screen
and playing with them. Opera and maybe others have been playing with 3D
canvas operations - if only we could put an <svg> into a <canvas> so
that we could read the pixels back from our <svg> or implement the get
Pixel value and put Pixel value operations from <canvas> then we'd have
something.

	

	I think the experience with Photoshop and Illustrator indicates
that it's a lot easier to put pixel stuff into a vector environment than
to do it the other way around.

	

	My only concern remaining was that HTML5 would adopt <canvas>
and ignore <svg> in such a way that implementers might be able to
continue to ignore SVG. Doug seems optimistic that that won't happen,
and he knows how this stuff works, so I think we can relax a bit more
now.

	

	In the long run, with the fact that Google now supports (some)
SVG in Chrome, it may soon be a moot point. 

	

	I would be delighted if some one could put some really simple
and some really cool demos in the SVG-wiki that show a) how to use
canvas and b) how to combine the use of canvas with that of svg. The
symbiosis could be very cool!

	

	David