W3C home > Mailing lists > Public > www-svg@w3.org > November 2005

Re: [SVGMobile12] Comments: Multimedia

From: T Rowley <tor@cs.brown.edu>
Date: Fri, 11 Nov 2005 17:07:40 -0600
Message-ID: <4375243C.8000206@cs.brown.edu>
To: Chris Lilley <chris@w3.org>
Cc: www-svg@w3.org

On 11/11/05 2:22 PM, Chris Lilley wrote:
>>Allowing implementations to opt-out of implementing the SVG rendering 
>>model (ordering/transform) of <video> seems like a bad thing for both 
>>the cleanliness of the specification and interoperability between 
>>implementations.  If a graphic element is to be added to the SVG 
>>specification, it should be required to be rendered according to the SVG 
>>rendering model.  <video>'s "transformBehavior" and "overlay" attributes 
>>should be removed along with these two sections.
> We would like the world to be like that. Unfortunately the real-world
> constraints of limited cpu power, battery life, etc intrude sometimes.
> The way we solved this was to allow a video to be either represented as
> a point or as a rectangle. In both cases, they obey the usual rules for
> transformation and ordering. However, in the case of video described as
> a point, the eventual on-screen location this point then becomes the
> anchor for the center of the axis-aligned video.

The description of this pinning says that the width/height attributes 
should be ignored if present, which seems to suggest that behavior of "A 
value of zero disables rendering of the element." (12.3 width/height 
attribute description) shouldn't apply.  If that isn't the intention, 
the specification needs some language update.

> This was necessary to allow video to be used at all on smaller devices,
> and allows some useful optimisations for larger ones. It was the
> cleanest way that we found while also meeting the requirements for this
> much-requested feature.

Having a major feature work intentionally in incompatible ways across 
implementations seems like a major problem for the specification.  What 
about a compromise position that includes these two attributes to allow 
content developers to generate "easy" content for less capable devices, 
but require implementations to implement both possibilities of the 
attributes?  Since implementations already need to be able to render 
raster images in the SVG painting model, it seems the worst case 
additional code would be something to read back a video frame from the 
framebuffer/accelerator (if the hardware supports some of the codec) and 
a colorspace conversion.
Received on Friday, 11 November 2005 23:08:07 UTC

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