[webkit-dev] KWQ Graphics code on Windows

[Kevin Ollivier]

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
>