Opened 9 years ago
Last modified 9 years ago
#87 new task
cairo: Import and build upstream sources
Reported by: | dmik | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | cairo | Version: | |
Severity: | medium | Keywords: | |
Cc: | dryeo |
Description
It's time to move cairo here as many projects need it and we want to provide our own patches in a convenient way.
Attachments (5)
Change History (25)
comment:1 by , 9 years ago
Component: | *none → cairo |
---|
by , 9 years ago
Attachment: | 0001-Don-t-unconditionally-link-against-librt.patch added |
---|
by , 9 years ago
Attachment: | 0002-Workaround-for-systems-lacking-clock_gettime.patch added |
---|
by , 9 years ago
Attachment: | 0003-Move-OS-2-module-init-from-cairo-os2-surface.c-to-ca.patch added |
---|
by , 9 years ago
Attachment: | 0004-Rewrite-cairo-os2-surface.c-to-remove-app-specific-c.patch added |
---|
by , 9 years ago
Attachment: | 0005-Add-cairo-os2-printing-surface.c-patterned-after-cai.patch added |
---|
comment:2 by , 9 years ago
Note that version 1.12.0 doesn't require patches 0001 and 0002 as these problems were already solved upstream since the patches were made. The need for the rest of the patches is TBD. Dave, if you have any overall knowledge on what they do, please share it.
comment:3 by , 9 years ago
To quote Rich,
BTW... The final version includes code that Moz doesn't use but
would be useful to an OS/2 developer (if there are any anymore).
The existing code maps a cairo-os2-surface directly to a window:
both the surface and the window are the same size, and a point at
25,35 on the surface appears at 25,35 in the window.
The new code lets part or all of a surface be mapped to any place on
some OS/2 bitmap (where "bitmap" could be a real bitmap or a window).
So, you could use Cairo to generate an image that appears anywhere
within a window (along with native content). Or, you could create
multiple images, then cut them up and write each part to, say, a
series of OS/2 bitmap files.
If I had any time, I might even try using some of this stuff myself...
comment:4 by , 9 years ago
IIRC, It should be noted that for Mozilla to use external Cairo, Cairo needs to also have the tee surface enabled. There was also some problems with some of the header stuff being moved from public visibility to private headers
comment:5 by , 9 years ago
Cc: | added |
---|
comment:6 by , 9 years ago
Rich also did plain code cleanup, getting rid of all warnings when using the toolkit headers and most when using the EMX headers according to a different message. That would have been with GCC 4.4.1
comment:8 by , 9 years ago
The strange thing regarding Cairo and mozilla is that mozilla uses Pango which also uses Cairo. Mozilla needs external Pango (which obviously uses external Cairo) but allows to use its own Cairo source at the same time which would eventually make use of two separate Cairo runtimes...
comment:9 by , 9 years ago
I had an older Debian Linux where the system Cairo was too old and Pango was fine. Rebuilding Firefox to use the internal Cairo would have been one solution (I updated Debian to the unstable branch). Distros such as Debian are very slow to update their stable branch and in a production setting updating the system Cairo could be dangerous. There's also the possibility that Cairo was not compiled with the right options for Mozilla, eg the tee surface.
comment:10 by , 9 years ago
For tee, it builds by default on Fedora-like systems so do we. See also #91. I already tried building Mozilla with this external cairo build, but it still references to CAIRO_SURFACE_TYPE_OS2_PRINTING in a couple of places. I will try to get rid of it for now and provide printing through CUPS instead.
comment:11 by , 9 years ago
It turned out that there are changes by Rich not related to printing that Firefox relies upon (i.e. diffs 0003 and 0004). I will have to apply these diffs to trunk in order to continue. This will take some time since in 1.12.0 the cairo tree got some significant changes compared to http://cgit.freedesktop.org/cairo/commit/?id=d66d9cd777c362e2f99a41aa77bbe3428cf0c60d which is the commit the diffs are applied against. In particular, they got rid of cairo-system.c
.
comment:12 by , 9 years ago
Patch 0003 applied in r1272. Almost unchanged but I had to adopt it to the new source layout and also changed BUILD_CAIRO_DLL to CAIRO_OS2_STATIC_BUILD (similarity with WIn32) which is not defined by default since cairo is built as a DLL by default.
comment:13 by , 9 years ago
Regarding patches 0004 and 0005, this is much harder to apply since I see a lot of structural changes to e.g. cairo-os2-surface.c
in between of d66d9cd777c362e2f99a41aa77bbe3428cf0c60d and v1.12.0... This means that the os/2 bits were either modified by some third person (i.e. not Rich) or this is an automated source update. But it doesn't look like the latter because the changes are quite complex. I need to check the cairo log.
comment:14 by , 9 years ago
BTW, Cairo version in mozilla is 1.9.5. Perhaps we should have taken this as a start instead of 1.12.0... (or at least 1.11 something which matches d66d9cd777c362e2f99a41aa77bbe3428cf0c60d). Anyway, I will try to adopt the existing patches first and then we decide.
comment:15 by , 9 years ago
Log analysis shows that this was basically blind update of the OS/2 code during global refactoring. Ok, good. I will apply Rich's patches somehow anyway.
comment:16 by , 9 years ago
Patch 0004 is committed in r1273. Note that it was partly modified to match the new upstream code and incorporate OS/2 fixes blindly applied by cairo maintainers after the patch was initially created by Rich. In particular, the following functions from the patch were dropped:
_cairo_os2_surface_composite _cairo_os2_surface_fill_rectangles _cairo_os2_surface_composite_trapezoids _cairo_os2_surface_create_span_renderer _cairo_os2_surface_check_span_renderer
This is because the composer part was changed upstream and they are not necessary any more. Given that they were just forwarders to generic versions (i.e. to _cairo_surface_composite
etc.) I don't think that we have to care about them. What we probably have to care about at some point is the new composer fallbacks added by http://cgit.freedesktop.org/cairo/commit/src/cairo-os2-surface.c?id=59a5c9d34c01e398dd56c3ca9afa6a08427c1270:
_cairo_surface_fallback_paint, _cairo_surface_fallback_mask, _cairo_surface_fallback_fill, _cairo_surface_fallback_stroke
This new API looks like a replacement for the removed API, but that's just a guess so far. In either case we were at the generic code back then and we are at the fallback code now, which looks pretty much the same. Given that we don't have any real native APIs for composing, this may simply work out as it did before.
Note that after this commit the OS/2 bits of cairo in this repository look almost identical to the OS/2 bits of cairo provided with Mozilla (except the printing surface stuff which isn't applied here yet). There are a few minor differences (like debug printf's in Dive code and in a few other places in the Mozilla version, or cairo_os2_surface_t
absence from the public headers in the repository version). These differences (in particular, the removal of cairo_os2_surface_t
from public headers) leave an impression that the code in Patch 0004 above is a bit newer, refreshed version of what was applied to the Mozilla repository. Anyway, these differences are not to make any difference in behavior.
comment:17 by , 9 years ago
in r1284 I fixed a bug that would do image surface's reference counting wrong in the new code. I looked up this code in the Quartz backend and it seems that the Quarts backend is not maintained because this is a pretty nasty bug that would have been spotted otherwise. The XCB backend does it right (the same as in the above commit).
However, there are some oddities in the Cairo behavior in Mozilla, see https://github.com/bitwiseworks/mozilla-os2/issues/147#issuecomment-180472525. It may be related to the new compositor and to these fallbacks that we use on OS/2 (see comment:16). This needs checking.
comment:18 by , 9 years ago
Type: | task → defect |
---|
I will try to import the latest cairo 1.12 version which is 1.12.18 (which is just 16 months old) which may contain fixes for the fallback compositor problem as I can't find any native OS/2 problems that could affect it.
comment:19 by , 9 years ago
Type: | defect → task |
---|
comment:20 by , 9 years ago
Cairo is updated to 1.12.18 in r1342 and the repaint problem in FF has gone, so it was definitely an upstream bug. Good.
I decided to start with version 1.12.0 because this is the closest public release to v1.11.something (revision d66d9cd777c362e2f99a41aa77bbe3428cf0c60d in http://cgit.freedesktop.org/cairo/) which Dave suggested me as the last one he successfully applied Rich's patches to.
This version is already committed and I already made the cairo DLL built on OS/2 with just a small patch in r1256 (some build problems in
util
but that's to be sorted out yet). I didn't apply any patches from Dave or Rich yet because I first want to test it with Firefox as is.I will attach all patches I have now anyway, just to have them for possible reference.