[webkit-dev] KWQ Graphics code on Windows

Kevin Ollivier kevino at theolliviers.com
Fri Jan 20 21:43:35 PST 2006

Hi Krzysztof,

On Jan 20, 2006, at 4:41 PM, Krzysztof Kowalczyk wrote:

> On 1/20/06, David Hyatt <hyatt at apple.com> wrote:
>> How big is the wxWidgets DLL (or DLLs)?
> Hard to tell because they don't provide binaries, but judging from
> wxPython 2.6.1, at least 4.7 MB on Windows (the size of
> C:\Python24\Lib\site-packages\wx-2.6-msw-unicode\wx\wxmsw26uh_vc.dll,
> but there's more stuff).

Right, but the other stuff wouldn't be needed for WebKit; they're add- 
on UI controls and wxPython wrappers, basically. Also, wxPython  
builds about everything wx offers into the DLL (you can build smaller  
DLLs with a subset of controls), and leaves assert handling on, along  
with some debugging code that wouldn't be included in a "regular"  
release app. So 4.7MB is pretty much the "kitchen sink" estimate;  
WebKit would probably ship something smaller than that. To be honest,  
I use the wxPython DLL myself as none of my clients have complained  
about download size and it's convenient to have everything at your  
fingertips if you need it.

In any case, I will try building using the modular DLL option, which  
builds several smaller libraries instead of one big one (I figure  
we'll need base, core, and maybe net), and see how much we can trim  
off the size. I'll report back when I get some hard numbers.

> wxPython doesn't seem like a good idea - it's a *huge* (size and
> complexity) dependency.

(Side note: obviously we would be using wxWidgets itself, not the  
wxPython wrappers, for a WebKit backend.)

I admit I'm biased here, but I feel that's an exaggeration. The most  
complex way of solving the problem, IMHO, would be to roll a new/ 
custom API; it will be the most maintenance work and require the most  
initial design time and implementation effort, with the size benefits  
being a savings of, at most, a few MB of disk space on the user's  
computer. Then there's the optimization argument, but wxWidgets uses  
GDI under the hood and provides access to internals in most cases, so  
native optimizations above and beyond what the wx API offers can be  
made where needed. Also, the wxWidgets API, unlike other APIs, has  
been around and stabilized for far more than 1-2 years. The wx APIs  
get a fair amount of testing, and if you check the mailing lists,  
you'll see they're quite active, a sign IMHO of a healthy and active  
development community.

It seems to me using an existing API brings more benefits than it  
takes away, but then again I do have to admit that I don't see why a  
few MB of disk space is such a huge issue. After all, look at iTunes 
+Quicktime - that's a 34MB download, and takes ~100MB disk space, but  
most people don't seem to mind. :-) Compressed, wx will probably add  
1-2 MB to the download, if that, and 5 MB max to the disk space  
requirements. I personally don't think that's unreasonable.


> -- kjk
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list