[webkit-dev] KWQ Graphics code on Windows
mjs at apple.com
Tue Jan 31 00:46:48 PST 2006
On Jan 19, 2006, at 6:54 PM, Kevin Ollivier wrote:
> Hi all,
> On Jan 16, 2006, at 3:52 PM, David Hyatt wrote:
>> I would guess that Cairo requires gdiplus.dll.
>> I think GDI+ is what we should go with initially. Cairo might be
>> interesting as a way to do SVG eventually, but for now I think we
>> should not define SVG_SUPPORT and basically not worry about SVG.
>> The initial goal should be the bring-up of the HTML rendering
>> portion (SVG can come much later), and I don't think Cairo really
>> provides much of any benefit for that (although I'd be happy to be
>> proven wrong).
> Also, the wxWidgets library's drawing classes (wx*DC) are another
> solution to this that is cross-platform. (wxArt2D is a add-on
> library that has SVG support too.) The "con" of course is the added
> dependency, but the pluses are that:
Does wxWidgets drawing support transparency and compositing efficiently?
> 1) cross-platform, so more bang for the buck
> 2) share the support burden (wxWidgets developers will improve/test
> the graphics APIs as well, meaning less changes you need to make)
> 3) pre-packaged workarounds for a lot of Win bugs, and GTK too. ;-)
> Apps like Mozilla and OpenOffice.org took the approach of writing
> their own "cross-platform" toolkit APIs, with an implementation for
> each platform, and sooner or later support for each platform got
> out of sync, usually with the Mac being on the receiving end of the
> neglect. As someone who tried very, very hard to get Mozilla's
> embedding engine to run properly on Mac, I can tell you that the
> Mac guts were very out of date and very tied into the Mozilla
> application. I looked at OOo long enough to know making it work on
> Mac would be such a challenge that it needed far more than a couple
> of people with a lot of dedication. It's not even known when
> NeoOffice will run on the Intel Macs...
> Just my $0.02 but I've found that unless support for other
> platforms is absolutely critical (and thus you can be assured that
> ample resources will be devoted to it), the best solution is the
> one that reduces maintenance, and maximizes developer support, as
> much as possible. A wxWidgets port has already been started,
> actually (see http://developer.berlios.de/svn/?group_id=3786), and
> I'd definitely be happy to help out.
I don't think we want to move away from CG on the Mac. As far as
drawing code, I would want to see some evidence that it has the
performance and graphical capabilities to support a modern browser.
Does it do compositing and double buffering for instance?
More information about the webkit-dev