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
_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev
