W3C home > Mailing lists > Public > www-svg@w3.org > October 2009

Re: [Rendering Order] Some early feedback

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Mon, 26 Oct 2009 15:05:39 +0200
To: www-svg@w3.org
Message-Id: <200910261405.39326.Dr.O.Hoffmann@gmx.de>
Jonathan Watt:
> "3D" transforms are just an affect that changes an elements appearance as
> if it was being transformed in 3D, but they actually have no affect on its
> "depth" or rendering order. Only 'render-order'/'z-index' would. Maybe
> someone can come up with a fantastic, relatively easy to grasp proposal on
> how to change that, but I seriously doubt it. If you want real 3D as
> opposed to pseudo 3D, then probably its better to use something like WebGL
> (possibly using it to render SVG into planes that can then be manipulated
> in true 3D).

Well, often applications are simple enough or can be decomposed in
simple enough problems to be presented with SVG.
I think, it is not very important which library or number crunchers an
author uses (I prefer fortran or PHP), if the SVG output is
sufficient to represent the intented result without too many
redundancies (for example big file size containing only
a lot of data because SVG is not capable to handle it in a
problem oriented way).
And of course such a z-index functionality as well as the '3D' proposal
is a big progress to reduce redundances and complexities, with the 
result, that an author can solve the same problem with a 10kB SVG 1.2
file instead of an 100MB SVG 1.1 file and a lot of number crunching
just to create this 100MB file from the 1kB raw data describing the
original problem.

Not sure, if it is fantastic, but the proposal I'm currently working 
on, solves among other more important problems those of simple
3D data as well in a relatively simple way. Combined with a z-index
functionality this could be a pretty convenient way to provide simple 
3D data representations with low file size and much less author efforts 
than without:

Received on Monday, 26 October 2009 13:10:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:24 UTC