Apache OpenOffice (AOO) Bugzilla – Issue 70519
Support cairo canvas backend also on Windows
Last modified: 2009-07-20 15:56:57 UTC
With relatively small changes it is possible to use cairocanvas also on Windows. Will attach patches. Will also eventually set up a CWS.
Created attachment 39818 [details] Patch to config_office/configure.in
Created attachment 39819 [details] Create cairo/prj/build.lst
Created attachment 39820 [details] Create cairo/prj/d.lst
Created attachment 39821 [details] Create cairo/makefile.mk
Created attachment 39822 [details] Create cairo/cairo-1.2.4.diff
Created attachment 39823 [details] Patch to canvas/prj/build.lst and various files in canvas/source/cairo
Created attachment 39824 [details] Patch to vcl/inc/bitmap.hxx and vcl/win/source/gdi/salbmp.cxx
Created attachment 39825 [details] Patch to canvas/source/cairo/cairo_devicehelper.cxx
The above patches should hopefully give an impression of what changes are necessary. What is missing from the above is a check to configure.in to verify that the cairo-1.2.4 tarball is in cairo/download if a local cairo is wanted. As this work partially overlaps Radek's further work on cairocanvas there might be some glitches in the patches, although I tried to include only the Win32 bits here. The patches assume that on Unix we always use a system cairo, and on Win32, if we use cairo, a local one. cairo is built as static library (well, actually a separate library for pixman and cairo, I didn't figure out how to combine two separate built .lib files into one) as it is linked only into the cairocanvas UNO DLL. I include a patch to cairo so that the MMX goodness is used also when building with MSVC.
pl->thb: please have a look
Accepted, provided the mentioned things are sorted out (configure stuff, merging with rodo's changes).
Btw, is it OK to introduce the "cairo" folder directly under the top level? Will that require some extra bureaucracy, making "cairo" a "project" or whatever? Or should it go under "external"? Or is "external" only for stuff that is used as such (like gdiplus.dll) and not compiled?
@tml: aw, here you mention something - cairo clearly needs to go to external, but before committing that, we need legal approval for it. Can we maybe make that an external *dependency*, like on Linux? Would speed things up, really...
As you (should) know, there are no official Windows binaries for 3rd-party Open Source libraries like cairo. Perhaps what comes closest to being "official" is the cairo binary package distributed from ftp.gtk.org (which, surprise, is built and distributed by me). That provides a DLL, libcairo-2.dll. However, that build of cairo includes the svg, pdf, ps, and png surface backends, not just the win32 surface backend that cairocanvas needs. Especially the png surface backend is troublesome, as it then pulls in a dependency on libpng and zlib, for which again the situation is the same, there are no official Windows binaries. Just building cairo as part of OOo as static libraries, not as a DLL, is much simpler. I would say the cairo situation is very analoguous to the jpeg library: OOo doesn't on Windows use an external jpeg library either, although there presumably exist several ready-built binary distributions of the jpeg library as a DLL to choose from ;) (But again, as far as I know, none that could be called "official".) Instead, the jpeg library is built as part of OOo as a static library. BTW, for zlib there actually *is* an officially blessed Win32 DLL, distributed from zlib.org. Still OOo doesn't use that as an external dependency, but builds its own static zlib library. To add insult to injury, this is the outdated zlib 1.1.4, while the current version is 1.2.3. Why? Should I open an issue for that?
@tml: re zlib outdatedness - yes, might be worthwhile to file an enhancement issue (owner mav, I'd guess). Regarding cairo, the problem is perfectly clear to me - please read my comment as a hint on how upstreaming of the OOo parts can be significantly sped up (still, every packager would then need to somehow include/provide a cairo binary).
tml: since you are already able to create a distribution of cairo on ftp.gtk.org, why not then provide also, on ftp.gtk.org, a slimmed (& static?) version of cairo, that only includes the necessary parts (win32) for windows? Then you could just describe that URL in the configure scripts, if cairo is not found on windows platform. I think that including full sources of libraries that are part of basic distributions in e.g Linux dists, is just asking for trouble. Linux dists like to keep up-to-date with libraries, and having ancient versions lingering in OOo causes OOo code to become a jungle of #IFDEFs (necessary for cross-platform compatibility). It's much better to keep also the win32 version up-to-date elsewhere and ask people to download that. The configure scripts can always raise the minimum version, if incompatibilities are found. I have seen too many times how difficult and long process it is to get a library version updated on OOo CVS. It's not worth it. Besides, when there is a need for OOo specific library patches, they should be upstreamed (it at all possible), not left lingering in OOo CVS. Also Mac OS X has established ways (fink, darwinports) of getting library dependencies, so there is no need to have cairo sources in OOo CVS, for that platform either.
thb, do you agree with mox? Should I just set up an external distribution of a static cairo library, and modify my patches to use that in OOo?
@tml: if you can do that, this would indeed be my favorite solution. As pointed out, including cairo in OOo cvs includes all kinds of overhead (legal review and whatnot). And it's completely safe for the user, as there's an automatic fallback to vclcanvas (if cairo.dll is not found) anyway. Assuming that this'll work, setting a target.
OK, committed what's there on CWS wincairo01 (except for the cairo lib changes). @tml: please take over again (either accept as-is, or provide the missing parts for an external cairo).
Hi all, tml & thb: any traction on this issue/cws? Is there any schedule to get it integrated? AFAIK everything should be just fine for integration... It would help my work in issue 69066, if this code would be in OOo proper. Thanks.
Retargetted to 2.3, still some outstanding work. @mox: please poke tml, easiest way to get this in is pre-packaged cairo for windows (plus the configure magic).
Will refresh my memory how to work with CWSes again and check out wincairo01.
Dear developers, are we on track for 2.3 with this issue? Thank you very much for your attention!
Re: comments from mox Thu Nov 2 10:33:15 +0000 2006 > tml: since you are already able to create a distribution of cairo > on ftp.gtk.org, why not then provide also, on ftp.gtk.org, a > slimmed (& static?) version of cairo, that only includes > the necessary parts (win32) for windows? I do provide a cairo DLL with just the win32 surface and font backends compiled in. (look in http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/ for cairo-<version>-win32-only.zip) But no static library, alas.
tml: Yes, I found that out already. Take a look at the newest patch in issue 74170, it has the appropriate urls to enable prebuilt cairo library support for win32 too. However, I need somebody to test it on Windows and to (maybe) provide an alternative to curl (needed for downloading the files).
hmmh, ok so the url is not the correct one, but that's simple to change. Getting the download mechanism to work on Win32 is the real problem.
tor - what's the status here ?
Michael: the win32 port is in cws cairoquartz01, as well as the prebuilt-cairo support for win32, and configure changes. The cws is waiting for testing + first integrating cws:s presfixes12 and aquavcl01, as they have big effect on code / testing of the code.
I have testing of cairoquartz01 cws on linux in my todo list. Tor, does it build/work OK on windows for you?
Please set target according to the target of the cws this issues is fixed in.
Are we going to miss 2.4 with this issue?
kpalagin: If this code is important to you, then feel free to: 1) re-open cws wincairo01 2) copy all the code from cws cairoquartz01 to cws wincairo01 3) remove any macosx/quartz related code from cws wincairo01 4) get cws wincairo01 through all the OOo processes into the CVS. The VCL part of Mac OS X port has been heart-transplanted recently (Carbon -> Cocoa) and as a fallout of that, the changes in cws macosxquicktime01 need to be integrated, before cairo canvas works on Mac OS X.
Cairo library is known to not support Win 9Ñ…. However, drop of Win9x support has been proposed (http://www.openoffice.org/servlets/ReadMsg?listName=releases&msgNo=11377). If accepted, should it enable cairo on Windows?
Maybe 3.0?
Anyone able to build the cws cairoquartz01 (that includes the win backend too) on Windows machine (and using --enable-cairo in configure)? the cws hasn't been built (with --enable-cairo) on Windows for a long time. Feedback would be more than welcome.
Now with the DirectX canvas that is hardware accelerated, the cairo canvas is less attractive on Windows. But yes, we still build it on Windows, too, in ooo-build. Look there for current patches.
tml> cairo canvas is less attractive on Windows What does it mean? Can you attach screen shoots, please? Is present any other ways for antialiasing?
mr_smyle: I mean that the DirectX canvas offers the same (more or less) anti-aliasing niceness. No screenshots, this is just based on my visual impression looking at some sample slideshows. It is also much lighter on the CPU as it uses hardware acceleration. (At least I assume it does, as the difference in CPU usage is so significant. Or then the cairo canvas really does a lot of unnecessary work.)
As I understand we talk about antialiasing in figures: Calc - for example connection lines to notes Draw - figures tml: Now I can't see any anti-aliasing in Draw in figures: Screenshot: http://www.lecom-ltd.com/download/ooo/cairo01_draw_screen.png Export: http://www.lecom-ltd.com/download/ooo/cairo01_draw_export.png fig1 - clear export fig2 - edited selection in GIMP - antialiasing (this is nearly to what is needed on Screen and on Export) Who will do "fig2" anti-aliasing? DirectX or cairo?
@mr_smyle: the canvas (any of them) is currently only used for slideshow. we plan to use it in Draw/Impress for 3.0 as well.
tml: and for calc comments, and for exporting figures from draw?
mr_smyle: What you are asking for, is that the canvas (rendering) would be used in several parts of the openoffice.org. That is completely outside of the scope of this bug. This bug is not about _adding_ anti-aliasing to various parts of OpenOffice.org. Only that _support_ for anti-aliasing is implemented in canvas module itself (via cairo). This bug is about one _backend_ of canvas. There is also directx backend that more or less provides the same antialiasing etc. as cairo backend, so from your perspective, there is no difference which backend you use (cairo/directx). Well, only that directx one is probably faster as it has been optimized better. For application level antialiasing support, see: http://wiki.services.openoffice.org/wiki/DrawingPrimitives
Initial cairo win backend is now done. Need to get this integrated now, before other large canvas module changes disrupt things again. cairo win backend is not enabled by default. Marking fixed.
Reassigning for QA
cairo_win32_cairo.cxx missing.
Ah, my fault. Fixed a bunch of warnings and a few win32 build breakers. Everything ok now.
Verified.
This issue is closed automatically and wasn't rechecked in a current version of OOo. The fixed issue should be integrated in OOo since more than half a year. If you think this issue isn't fixed in a current version (OOo 3.1), please reopen it and change the field 'Target Milestone' accordingly. If you want to download a current version of OOo => http://download.openoffice.org/index.html If you want to know more about the handling of fixed/verified issues => http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues