[Webkit-unassigned] [Bug 5971] svg content doesn't work in <image> <img> or <feImage> tags

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=5971


macdome at opendarwin.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #12075|0                           |1
        is obsolete|                            |




------- Comment #12 from macdome at opendarwin.org  2006-12-27 23:11 PDT -------
Created an attachment (id=12076)
 --> (http://bugs.webkit.org/attachment.cgi?id=12076&action=view)
An updated hack, with better memory management (just code see old patch for
tests)

So I looked a little bit at ways to avoid having SVGImage create its own Page. 
Unfortunately I don't see any way to make that work inside SVGImage.

CachedImage objects are not tied to a page or a frame.  Image objects, are thus
not tied to either.  Even if they were, passing the Page into the image and
creating a frame for it would change the mainFrame on the page, unless we were
also to pass an ownerElement to the Frame constructor.  We have no such element
inside SVGImage unless we also manage to pass down the HTMLImageElement (or
SVGImageElement) down, but that doesn't necessarily work for background images
or filters, so that's a no go.

Another thought would be to teach the caching system to abort any CachedImage
load when it sees it trying to load image/svg+xml, and instead do a
requestObject load like embed/object do, or somehow "half load" the image
inside SVGImage, and then have something outside (like HTMLImageElement) know
how to finish the load.  That also doesn't sound optimal, given the fact that
images should be usable from backgrounds, filters, etc without lots of extra
code.

Another possibility is to ignore the Frame/FrameView/Page setup entirely and
just directly create an SVGDocument, decode the data stream with our own
Decoder, and create our own parser, etc.  The problem I forsee with that is
that things in Document (and the DOM tree) likely expect to have a Frame.   
I'm not certain of that requirement however.  It would be a substantial amount
of work to find out how required Frame objects are though.  (Unless hyatt,
darin, mjs care to comment on this possibility.)

So that leads us back to creating or own Page/Frame/FrameView stack.  The
problem here has become much harder since I initial started on this bug.  
WebCore is now very very tied into WebKit.  Page and Frame classes now depend
on being passed client objects and crash when they don't exist.  So to make
this patch work, I created (really ugly!) dummy objects, which are completely
empty.  This solution could work, except that it's likely to be very brittle. 
I can forsee a solution like this breaking the build constantly any time
someone wished to change a client.

I'm interested to hear your thoughts.  The attached patch is actually quite
stable (as far as I've seen) and doesn't leak (any more than the dummy objects
which are allocated once).  The code is a bit ugly, with all the dummy client
classes embedded inside SVGImage.cpp.

If this hack wasn't so brittle, I would actually seriously propose it for
landing.

I'm very hesitant to start rounding out the corners of this patch by solving
things like tiling, size negotiation, etc.  Those should all be pretty easy and
quick once a simple architecturally-sound skeleton is landed.  Until then, I
think solving the smaller issues is just wasting my time as this patch will
just rot until a way can be found to wire this into the loading architecture
for real.

I'm interested to hear your comments.


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