- From: T Rowley <tor@cs.brown.edu>
- Date: Fri, 11 Nov 2005 17:07:40 -0600
- To: Chris Lilley <chris@w3.org>
- Cc: www-svg@w3.org
On 11/11/05 2:22 PM, Chris Lilley wrote: >>12.3.1/12.3.2 >> >>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