[Webkit-unassigned] [Bug 15443] SVGImage does not support sub-resource loading

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=15443





--- Comment #20 from Cosmin Truta <ctruta at chromium.org>  2011-02-09 10:29:03 PST ---
(In reply to comment #19)
> > In short, to make a comparison with HTML, external images (non-HTML) are embedded via the <img> tag, while external HTML files are embedded via the <iframe> tag, and the separate logic applies to each of these two separate cases by design. On the other hand, in SVG, external SVG images are embedded in the same manner as non-SVG images via the <image> tag, and this can only work if the SVG's container has specific logic to handle the two cases separately. Since this logic does not currently exist in WebKit, it needs to be implemented, separately, in each of the SVG's container classes.
> 
> I'm not sure I follow here.
> The 'SVGImage' class, is used to render an external foo.svg images, when using <img src="foo.svg"..> from a HTML or SVG document (HTMLImageElement / SVGImageElement). When rendering pure raster images aka. <img src="test.jpg"> the class is not used.
> SVGImage doesn't integrate the 'target' documents rendering/DOM tree and the host document in any way.

I meant to say (if my understanding is correct) that, when rendering an SVG image, be it from an <img> tag in HTML, or from an <image> tag in SVG, the rendering below that SVGImageElement is disconnected from the rendering of the enclosing render tree above. Everything below that SVG image leaves in an isolated world, without communicating with the outside world, and that's because the concept of image (be it bitmap or vector) does not provide means for such communication.

Example:
When loading an SVG with subresources at the top level in the browser, or when embedding it in an HTML5 document, all the SVG elements, incl. subresources at the 1st level, show up in DumpRT. On the other hand, when loading the same SVG with subresources via the <img> tag in a HTML container, or via the <image> tag in an SVG container, or via the background-image CSS attribute, the subresources are not loaded, and the top-level SVG image is only a leaf (with nothing underneath) in DumpRT. Rendering of that top-level SVG image is done in a separate render tree, and the main render tree only sees the final array of pixels.

> This is exactly what SVGImage is used for, any-non .svg image source is handled through WebCore::Image, and external .svg images are handled through WebCore::SVGImage.

Yes, but Image and SVGImage do the same task: deliver pixels. RenderImage and RenderSVGImage sit in leaves.

I wanted to make a contrast between SVGImageElement and SVGUseElement. The spec does not allow <use> to refer to a whole external image file but let's ignore that for the moment. Compare:

<image href="foo.svg">
vs.
<use href="foo.svg"> (or <use href="foo.svg#TOP">)

In <use> case, the contents of "foo.svg" is part of the main render tree, just like the contents <iframe> is part of HTML's render tree, and everything that's below (animations, interactions, subresources, dynamic updates, etc.) is propagated all the way to the top.

In <image> case, the container sees only the pixels delivered either by BitmapImage or SVGImage, depending on whether href="foo.png" or href="foo.svg".

I will ask Adam to clarify if what I'm saying is unclear and/not entirely the way he meant it.
But from what I understood so far, I agree with him that it would have been better if <image> were restricted to foreign (i.e. non-SVG) images, while using <use> for handling external SVG content.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.