Bug 26295 - Make Webkit's SVG Implementation Smaller for Mobile Devices
: Make Webkit's SVG Implementation Smaller for Mobile Devices
Status: RESOLVED INVALID
: WebKit
SVG
: 528+ (Nightly build)
: Macintosh Mac OS X 10.5
: P2 Normal
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2009-06-10 11:50 PST by
Modified: 2010-02-19 21:44 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-06-10 11:50:18 PST
Webkits SVG implementation currently clocks in around 500K. I have spoken to people on the Android team, and they compiled out SVG because it is so large. The new Palm Pre's WebOS has also compiled out SVG, probably for similar reasons. This bug tracks tightening up Webkit's SVG implementation so that it can get on more mobile devices. Perhaps there are one or two key bottlenecks around code size that can be easily addressed?
------- Comment #1 From 2009-06-10 12:05:52 PST -------
SVG is simply huge.  The spec that is.  So I don't think this bug if very useful.  If you (or the android team) have specific steps theyd like to see taken.... like making ENABLE(SVG) smaller by breaking more of SVG out into other pieces, that's possible.
------- Comment #2 From 2009-06-10 12:29:39 PST -------
How is this bug invalid? The SVG implementation that we've been creating using JavaScript and Flash is about 55K with GZip compression on. Granted, we are using Flash's drawing primitives, but these are pretty low-level. We have much of SVG 1.1 including dynamic scripting with the DOM at a much smaller size than Webkits, including some of SVG Fonts, SMIL, and more. Yes, the spec is large, but that doesn't seem to cover the entire reason that Webkit's impl is very large (500K!).

While I didn't necessarily provide specific ways to make the SVG impl smaller, the goal of this bug is valid and should be left open.
------- Comment #3 From 2009-06-11 17:05:58 PST -------
(In reply to comment #2)
> How is this bug invalid? The SVG implementation that we've been creating using
> JavaScript and Flash is about 55K with GZip compression on. Granted, we are
> using Flash's drawing primitives, but these are pretty low-level. We have much
> of SVG 1.1 including dynamic scripting with the DOM at a much smaller size than
> Webkits, including some of SVG Fonts, SMIL, and more. Yes, the spec is large,
> but that doesn't seem to cover the entire reason that Webkit's impl is very
> large (500K!).
> 
> While I didn't necessarily provide specific ways to make the SVG impl smaller,
> the goal of this bug is valid and should be left open.

As discussed in private mails the bug is just too generic. More specific bug reports for individual areas of the code are needed. As I said in another mail, part of the problem with WebCore/SVG's size is because of the JS<->SVG interaction wrappers.
------- Comment #4 From 2009-06-11 17:08:05 PST -------
Where does the 500k number come from?  How is it measured?  Do we have any idea what contributes to this number?

Again, generic bugs like this are unactionable, thus not much use to the dev team.
------- Comment #5 From 2009-06-11 18:02:09 PST -------
My understanding is that the 500k number was heard from Google employees who have done compilation of WebKit browser for Android.  It would be great to get their feedback in this bug to get a little more specificity.
------- Comment #6 From 2010-02-19 21:44:09 PST -------
(In reply to comment #3)
> As discussed in private mails the bug is just too generic.

I'd also vote for keeping it open, as a meta-bug. Whenever one is able to break things down a bit (or find related bugs), blocker bugs would be added here. In the mean time, this makes it easier for watchers to keep away from the whole cake while still being notified of stuff (disclaimer: I'm a fan of meta-bugs). ;-)

With this in mind, I'd even suggest making it even more generic and remove the "for Mobile Devices" from the summary or, at least, place the expression in parenthesis: we are apparently interested in general shrinking possibilities, which affect all platforms (though naturally mobile implementations would benefit more from this).


(In reply to comment #5)
> It would be great to get
> their feedback in this bug to get a little more specificity.

+1 on this too.

I guess this could simply mean post something about this generic issue and place a link to this issue into a couple mobile development mailing lists...? Feedback from the Android team would be great but I'm sure there are other mobile communities of interest to gather here (for example Palm Pre, as stated in comment 0; I'm convinced there are more). :-)