We have several libraries we can choose from: - GDI - GDI+ - Windows Presentation Foundation (XP/2003/Vista only) - Cairo (portable) - Mozilla's choice, LGPL'ed Which should we use? They all have their pros/cons GDI is a C library, Windows only, hardware accelerated on Vista, semi-hardware accelerated pre-Vista GDI+ is object oriented, portable (sorta), hardware accelerated on Vista, software accelerated pre-Vista WPF is object oriented, not native C++, hardware accelerated on all supported platforms Cairo is a C library, portable, hardware accelerated depending on implementation
On Jan 16, 2006, at 3:04 PM, Justin Haygood wrote:
We have several libraries we can choose from:
GDI GDI+
The concern with GDI+ is that it only works on XP/2003/Vista as well, right?
Windows Presentation Foundation (XP/2003/Vista only)
I don't see this as an option.
Cairo (portable) - Mozilla's choice, LGPL'ed
Is Cairo built on GDI or GDI+? Will it work on Win2k? In order to do some of the SVG features, I assume GDI+ will be necessary though... dave
On 1/16/06, David Hyatt <hyatt@apple.com> wrote:
On Jan 16, 2006, at 3:04 PM, Justin Haygood wrote:
We have several libraries we can choose from:
GDI GDI+
The concern with GDI+ is that it only works on XP/2003/Vista as well, right?
GDI+ is redistributable on older platforms (98/2000/ME).
Windows Presentation Foundation (XP/2003/Vista only)
I don't see this as an option.
Cairo (portable) - Mozilla's choice, LGPL'ed
Is Cairo built on GDI or GDI+? Will it work on Win2k?
I don't know. I believe GDI. Should, Both GDI & GDI+ work on Windows 2000. In order to do some of the SVG features, I assume GDI+ will be
necessary though...
GDI+ is what Mozilla used to use. Cairo is used for SVG if you have Firefox 1.5. dave
On Jan 16, 2006, at 3:28 PM, Justin Haygood wrote:
On 1/16/06, David Hyatt <hyatt@apple.com> wrote: On Jan 16, 2006, at 3:04 PM, Justin Haygood wrote:
We have several libraries we can choose from:
GDI GDI+
The concern with GDI+ is that it only works on XP/2003/Vista as well, right?
GDI+ is redistributable on older platforms (98/2000/ME).
Yeah, true.
Windows Presentation Foundation (XP/2003/Vista only)
I don't see this as an option.
Cairo (portable) - Mozilla's choice, LGPL'ed
Is Cairo built on GDI or GDI+? Will it work on Win2k?
I don't know. I believe GDI. Should, Both GDI & GDI+ work on Windows 2000.
In order to do some of the SVG features, I assume GDI+ will be necessary though...
GDI+ is what Mozilla used to use. Cairo is used for SVG if you have Firefox 1.5.
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). dave
Agreed, GDI+ also is easier, its C++ just like KWQ, and it was designed for vector graphics afterall. My initial attempts (from long time ago.. pre open development WebKit, back when webcore-125.tar.gz is all i had to work with ;)) at porting KWQ to GDI+ was decent, but KWQRegion.cpp always gave me trouble, since it didn't correspond to GDI+ Region exactly and using Bezier Paths didn't work well either for some transformation stuff. I guess we can cross that bridge when we come to it? Initially, IntPoint, IntRect, etc.. in /platform would be a good place to go ahead and move to GDI+ on Windows since its mostly explicit casting to and fro stuff. On 1/16/06, David Hyatt <hyatt@apple.com> wrote:
On Jan 16, 2006, at 3:28 PM, Justin Haygood wrote:
On 1/16/06, David Hyatt <hyatt@apple.com> wrote:
On Jan 16, 2006, at 3:04 PM, Justin Haygood wrote:
We have several libraries we can choose from:
GDI GDI+
The concern with GDI+ is that it only works on XP/2003/Vista as well, right?
GDI+ is redistributable on older platforms (98/2000/ME).
Yeah, true.
Windows Presentation Foundation (XP/2003/Vista only)
I don't see this as an option.
Cairo (portable) - Mozilla's choice, LGPL'ed
Is Cairo built on GDI or GDI+? Will it work on Win2k?
I don't know. I believe GDI. Should, Both GDI & GDI+ work on Windows 2000.
In order to do some of the SVG features, I assume GDI+ will be
necessary though...
GDI+ is what Mozilla used to use. Cairo is used for SVG if you have Firefox 1.5.
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).
dave
On Jan 17, 2006, at 00:52, David Hyatt wrote:
I would guess that Cairo requires gdiplus.dll.
Last I checked FF with SVG support required gdiplus.dll on earlier Windows, so you're IMHO guessing right.
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).
Just a question from the sidelines, but is there really a need to prioritise? If there's early interest in getting SVG in WebKit to work on Windows should folks be diverted to the HTML portions? Of course I'm totally biased in saying so, but I figured if there are priorities at least I'd like to know why they're there :) -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Hi all, On Jan 16, 2006, at 3:52 PM, David Hyatt wrote: [snip]
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: 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. Thanks, Kevin
dave
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
How big is the wxWidgets DLL (or DLLs)? dave On Jan 19, 2006, at 6:54 PM, Kevin Ollivier wrote:
Hi all,
On Jan 16, 2006, at 3:52 PM, David Hyatt wrote:
[snip]
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:
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.
Thanks,
Kevin
dave
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
On 1/20/06, David Hyatt <hyatt@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). wxPython doesn't seem like a good idea - it's a *huge* (size and complexity) dependency. -- kjk
Hi Krzysztof, On Jan 20, 2006, at 4:41 PM, Krzysztof Kowalczyk wrote:
On 1/20/06, David Hyatt <hyatt@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. Kevin
-- kjk _______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
Hi all, On Jan 20, 2006, at 9:43 PM, Kevin Ollivier wrote: [snip]
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.
BTW, wanted to let people know that by building smaller libraries, the total dependencies were reduced to ~3.7MB. That's probably about the best we can do without actually having a list of classes we know we won't need. In any case, I guess the first question would be whether or not the added dependency in its current form would be acceptable. Thanks, Kevin
FYI, size of other dependencies: ICU Data DLL.. 8.44 MB ICU Common DLL.. 816 KB iconv (libxml2, libxslt needs this).. 868 KB libxml2.. 924 KB libxslt... 149 KB On 1/22/06, Kevin Ollivier <kevino@theolliviers.com> wrote:
Hi all,
On Jan 20, 2006, at 9:43 PM, Kevin Ollivier wrote:
[snip]
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.
BTW, wanted to let people know that by building smaller libraries, the total dependencies were reduced to ~3.7MB. That's probably about the best we can do without actually having a list of classes we know we won't need. In any case, I guess the first question would be whether or not the added dependency in its current form would be acceptable.
Thanks,
Kevin
_______________________________________________ webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
On Jan 19, 2006, at 6:54 PM, Kevin Ollivier wrote:
Hi all,
On Jan 16, 2006, at 3:52 PM, David Hyatt wrote:
[snip]
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? Regards, Maciej
Hi Maciej, On Jan 31, 2006, at 12:46 AM, Maciej Stachowiak wrote:
On Jan 19, 2006, at 6:54 PM, Kevin Ollivier wrote:
Hi all,
On Jan 16, 2006, at 3:52 PM, David Hyatt wrote:
[snip]
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?
As for transparency, yes, we have support for alpha channels; by compositing, do you mean support for blending together two separate pixels? (i.e. the get/setCompositeOperation code in QPainter) If that's the case, then this function, SetLogicalOperation, may have what you need: http://www.wxwindows.org/manuals/2.6.2/ wx_wxdc.html#wxdcsetlogicalfunction I'm not sure we have the three last operations in QPainter's compositeOperators list, but they could probably be added. I'll check into that. As for efficiency, at the moment I can only say that I don't see any noticeable performance issues, but I don't have hard data on hand for that. I'll ask about this on the lists as well.
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.
Actually, we have a CG-based implementation of wxDC on Mac. It's not on by default in 2.6, basically because we haven't determined how to properly handle the issue that CG doesn't support XOR operations the way the wx API expects it to. (Stefan Csomor would have more details as he wrote the CG implementation.) There's been talk about a new API, but it would have to use XOR under the hood on some platforms. I'm really hoping that after 2.6.3 is out (the 11th) we can find a solution to this so that we can make CG default. Anyways, outside of that issue, you can turn on the CG DC in include/wx/mac/carbon/ chkconf.h (the define is wxMAC_USE_CORE_GRAPHICS). I was actually only thinking of using the wx port on Mac for wx embedding (I already know of three apps I want to do this with!), but if you guys could use it for the native app too, that would be great. :-)
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?
We do have wxBufferedDC for double-buffered drawing, and I'll try to get some more hard data on the performance issue. Thanks, Kevin
Regards, Maciej
I would vote for GDI+ or cairo (it that order). Cairo is still supposed to be slow, is additional dependency and would increase code size. GDI+ is already there. WPF, for practical purposes, doesn't exist yet. I wouldn't feel comfortable writing against technology that didn't ship v1.0 yet. BTW: is there some kind of a plan or a list of tasks to be done for windows port? I might find the time to do work, but I wouldn't know where to start or what parts need work. I noticed that recently there was work on windows port from Justing and Dave Hyatt but it's not clear what's the end goal of this effort is and what are areas that are known to need more work (so that there is no work duplication or going in a direction that is different from what other people are doing). Krzysztof Kowalczyk On 1/16/06, Justin Haygood <jhaygood@spsu.edu> wrote:
We have several libraries we can choose from:
GDI GDI+ Windows Presentation Foundation (XP/2003/Vista only) Cairo (portable) - Mozilla's choice, LGPL'ed Which should we use?
They all have their pros/cons
GDI is a C library, Windows only, hardware accelerated on Vista, semi-hardware accelerated pre-Vista GDI+ is object oriented, portable (sorta), hardware accelerated on Vista, software accelerated pre-Vista WPF is object oriented, not native C++, hardware accelerated on all supported platforms Cairo is a C library, portable, hardware accelerated depending on implementation
On 1/16/06, Krzysztof Kowalczyk <kkowalczyk@gmail.com> wrote:
I would vote for GDI+ or cairo (it that order). Cairo is still supposed to be slow, is additional dependency and would increase code size. GDI+ is already there.
WPF, for practical purposes, doesn't exist yet. I wouldn't feel comfortable writing against technology that didn't ship v1.0 yet.
BTW: is there some kind of a plan or a list of tasks to be done for windows port? I might find the time to do work, but I wouldn't know where to start or what parts need work. I noticed that recently there was work on windows port from Justing and Dave Hyatt but it's not clear what's the end goal of this effort is and what are areas that are known to need more work (so that there is no work duplication or going in a direction that is different from what other people are doing).
I think the current (silent) consensus is to get higher level portions of WebCore to compile, and then work on implementing KWQ and other lower level classes. FYI: JavaScriptCore compiles on Windows. I have a patch to build it as a DLL in Bugzilla right now (submitted for a few minutes ago), though I use my own build system currently. It also works! (minus a "bug" in Microsoft's implementation of gmtime/localtime - not a bug perse since the spec allows what they do, but they don't follow the rest of the 'modern' libc implementations) Krzysztof Kowalczyk
On 1/16/06, Justin Haygood <jhaygood@spsu.edu> wrote:
We have several libraries we can choose from:
GDI GDI+ Windows Presentation Foundation (XP/2003/Vista only) Cairo (portable) - Mozilla's choice, LGPL'ed Which should we use?
They all have their pros/cons
GDI is a C library, Windows only, hardware accelerated on Vista, semi-hardware accelerated pre-Vista GDI+ is object oriented, portable (sorta), hardware accelerated on Vista, software accelerated pre-Vista WPF is object oriented, not native C++, hardware accelerated on all supported platforms Cairo is a C library, portable, hardware accelerated depending on implementation
webkit-dev mailing list webkit-dev@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev
participants (6)
-
David Hyatt
-
Justin Haygood
-
Kevin Ollivier
-
Krzysztof Kowalczyk
-
Maciej Stachowiak
-
Robin Berjon