Re: Webkit-gtk and MacOSX

[John Ralls <jralls ceridwen us>]

On Aug 25, 2009, at 10:10 PM, Kalle Vahlman wrote:

> 2009/8/26 John Ralls <jralls ceridwen us>:
> > Thank you both for hashing this out for me. I'll persevere with  
> > getting
> > Webkit-Gtk to build with quartz, then. I'm not sure I agree that  
> > it's "not
> > that big": WebKit.framework clocks in at 78M.
>
> Whatever the WebKit.framework is, with that size it's bound to include
> something in addition to the WebKit library. The shared library is
> just 15MB on Linux.
>
> I don't think we are still missing *that* much API after all :)

Well, first off, Webkit drags in a bunch of dependencies (libsoup  
comes immediately to mind, but there are others) which aren't  
necessarily required by other parts of the application being bundled.

Another major contribution is that MacOSX application binaries are  
roughly twice as big as Linux binaries because they must support two  
architectures (intel and power-pc) . Webkit is 4x, because it supports  
32-bit and 64-bit for each. Even with all of that, the WebKit library  
itself (the equivalent of webkit.so on Linux) is only 7M.  The WebCore  
library, tucked inside its own framework bundle inside  
WebKit.framework, is 63M, also with 4 architectures. There are also  
icon files, translations, and an application binary or two buried in  
each framework to account for the rest. Dividing 63 + 7 by 4 gets  
17.5, so the single-
binary Linux equivalent isn't that much different. I'm not at this  
point going to support 64-bit, so I guess I can expect WebKit-Gtk to  
add 43M  (35M of binary and 8M of support stuff) to a client app  
download, assuming the person doing the bundling wants to support PPC.

Since WebKit is already on every mac, it seems a waste of bandwidth,  
but if it's the only way to get WebKit to work with Gtk, it doesn't  
really matter.

Regards,
John Ralls