Summary: | build breaks on compilation after successful configuration | ||
---|---|---|---|
Product: | cairo | Reporter: | Claudio Fontana <sick_soul> |
Component: | general | Assignee: | Carl Worth <cworth> |
Status: | RESOLVED FIXED | QA Contact: | cairo-bugs mailing list <cairo-bugs> |
Severity: | normal | ||
Priority: | medium | ||
Version: | 1.4.10 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
URL: | http://www.niceties.it/cairo_build.html | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: | patch |
Description
Claudio Fontana
2007-08-29 08:42:49 UTC
commit 0cf3d0364c13ef761e7ddeb83848ff2c8245077f Author: Behdad Esfahbod <behdad@behdad.org> Date: Wed Aug 29 12:18:16 2007 -0400 [configure.in] Make PS backend require zlib too (#12210) The PS backend uses zlib these days. Make it depend on zlib being available like PDF has been doing. (In reply to comment #1) > commit 0cf3d0364c13ef761e7ddeb83848ff2c8245077f > Author: Behdad Esfahbod <behdad@behdad.org> > Date: Wed Aug 29 12:18:16 2007 -0400 > > [configure.in] Make PS backend require zlib too (#12210) > > The PS backend uses zlib these days. Make it depend on zlib being > available > like PDF has been doing. I see. Does cairo/Xlib also require Xrender in the same way now? In file included from cairo-xlib-surface.c:41: cairo-xlib-xrender.h:45:36: error: X11/extensions/Xrender.h: No such file or directory (In reply to comment #2) > (In reply to comment #1) > > commit 0cf3d0364c13ef761e7ddeb83848ff2c8245077f > > Author: Behdad Esfahbod <behdad@behdad.org> > > Date: Wed Aug 29 12:18:16 2007 -0400 > > > > [configure.in] Make PS backend require zlib too (#12210) > > > > The PS backend uses zlib these days. Make it depend on zlib being > > available > > like PDF has been doing. > > I see. Does cairo/Xlib also require Xrender in the same way now? > > In file included from cairo-xlib-surface.c:41: > cairo-xlib-xrender.h:45:36: error: X11/extensions/Xrender.h: No such file or > directory No, cairo is capable of rendering to X servers without Xrender, but nobody ever did the job of making it compilable without Xrender. So, in that sense, it's always been broken. We're waiting for someone motivated enough to send a patch. I personally started doing it a few times (including today), but it's not trivial and lacking enough motivation, I gave up again. If you want to give it a try, just start #if CAIRO_HAS_XLIB_XRENDER_SURFACE stuff out until it compiles and works... (In reply to comment #4) > If you want to give it a try, just start #if CAIRO_HAS_XLIB_XRENDER_SURFACE > stuff out until it compiles and works... > I started to look at it, I am thinking about splitting cairo-xlib-surface.c in two, stuffing everything that requires render extensions into cairo-xlib-surface-xrender.c, and possibly export an interface in cairo-xlib-surface-xrender.h to make available to cairo-xlib-surface.c . Still very cloudy, but the idea is to clutter with preprocessor conditionals as little as possible. ATM I have wrapped part of the struct _cairo_xlib_surface declaration in cairo-xlib-surface-private.h in an if like this: #if CAIRO_HAS_XLIB_XRENDER_SURFACE int render_major; int render_minor; Picture dst_picture, src_picture; XRenderPictFormat *xrender_format; XTransform xtransform; #endif but maybe something better will come to mind. Tomorrow I'll start going through the functions in the .c in more detail, trying to understand how this thing works. Btw, I've noticed that functions are referenced in a backend table/structure, and in some cases some of these functions only have an implementation that requires render extensions. Should I just put NULL there in these cases and hope for the best? (that applications still work?) For example, I singled out _cairo_xlib_surface_create_similar, _cairo_xlib_surface_fill_rectangles, _cairo_xlib_surface_composite_trapezoids, _cairo_xlib_surface_is_similar as currently being render-ext-only (or so they look to me). Does this make any sense? The domain is very unfamiliar to me. Claudio (In reply to comment #5) > (In reply to comment #4) > > If you want to give it a try, just start #if CAIRO_HAS_XLIB_XRENDER_SURFACE > > stuff out until it compiles and works... > > > > I started to look at it, I am thinking about splitting cairo-xlib-surface.c > in two, stuffing everything that requires render extensions > into cairo-xlib-surface-xrender.c, and possibly export > an interface in cairo-xlib-surface-xrender.h to make available to > cairo-xlib-surface.c . Still very cloudy, but the idea is to clutter > with preprocessor conditionals as little as possible. I don't think separating them makes much sense. > ATM I have wrapped part of the struct _cairo_xlib_surface declaration in > cairo-xlib-surface-private.h in an if like this: > > #if CAIRO_HAS_XLIB_XRENDER_SURFACE > int render_major; > int render_minor; > Picture dst_picture, src_picture; > XRenderPictFormat *xrender_format; > XTransform xtransform; > #endif > > but maybe something better will come to mind. > Tomorrow I'll start going through the functions in the .c in more > detail, trying to understand how this thing works. > > Btw, I've noticed that functions are referenced in a backend table/structure, > and in some cases some of these functions only have an implementation that > requires render extensions. Should I just put NULL there in these cases > and hope for the best? (that applications still work?) If you do NULL, cairo will use the fallback code. So yes. But you can also just return UNSUPPORTED. As I said, the current code does work with an X server without Xrender. So, you already got all the answers in there. Just follow what happens if Xrender is detected to be unavailable at run-time and make it do the same at compile time. > For example, I singled out > > _cairo_xlib_surface_create_similar, > _cairo_xlib_surface_fill_rectangles, > _cairo_xlib_surface_composite_trapezoids, > _cairo_xlib_surface_is_similar > > as currently being render-ext-only (or so they look to me). > Does this make any sense? The domain is very unfamiliar to me. There's at least _cairo_xlib_show_glyphs too. show_glyphs and composite_trapezoids should become UNSUPPORTED/NULL with no render I guess, the rest should already have paths working without Xrender. is_similar definitely should be available still. > Claudio > (In reply to comment #6) > (In reply to comment #5) > > I started to look at it, I am thinking about splitting cairo-xlib-surface.c > > in two, stuffing everything that requires render extensions > > into cairo-xlib-surface-xrender.c, and possibly export > > an interface in cairo-xlib-surface-xrender.h to make available to > > cairo-xlib-surface.c . Still very cloudy, but the idea is to clutter > > with preprocessor conditionals as little as possible. > > I don't think separating them makes much sense. I still think it would make sense to isolate the xrender stuff, but I will try to first implement it with a bunch of ifdefs, to see if I can get it to compile/work first. > > ATM I have wrapped part of the struct _cairo_xlib_surface declaration in > > cairo-xlib-surface-private.h in an if like this: > > > > #if CAIRO_HAS_XLIB_XRENDER_SURFACE > > int render_major; > > int render_minor; > > Picture dst_picture, src_picture; > > XRenderPictFormat *xrender_format; > > XTransform xtransform; > > #endif > > > > but maybe something better will come to mind. > > Tomorrow I'll start going through the functions in the .c in more > > detail, trying to understand how this thing works. > > > > Btw, I've noticed that functions are referenced in a backend table/structure, > > and in some cases some of these functions only have an implementation that > > requires render extensions. Should I just put NULL there in these cases > > and hope for the best? (that applications still work?) > > If you do NULL, cairo will use the fallback code. So yes. But you can also > just return UNSUPPORTED. > As I said, the current code does work with an X > server without Xrender. So, you already got all the answers in there. Just > follow what happens if Xrender is detected to be unavailable at run-time and > make it do the same at compile time. > > > For example, I singled out > > > > _cairo_xlib_surface_create_similar, > > _cairo_xlib_surface_fill_rectangles, > > _cairo_xlib_surface_composite_trapezoids, > > _cairo_xlib_surface_is_similar > > > > as currently being render-ext-only (or so they look to me). > > Does this make any sense? The domain is very unfamiliar to me. > > There's at least _cairo_xlib_show_glyphs too. show_glyphs and > composite_trapezoids should become UNSUPPORTED/NULL with no render I guess, > the rest should already have paths working without Xrender. > is_similar definitely should be available still. ok, is_similar without xrender will then just return the result of _cairo_xlib_surface_same_screen. I just thought, since the logic is already there and cairo already works if xrender is not present at runtime, what about providing a no-op render extension interface replacement module if xrender is not found, set the xrender_format to NULL, and let the existing code do the trick? Would you like this better? (In reply to comment #8) > I just thought, > since the logic is already there and cairo already works > if xrender is not present at runtime, > > what about providing a no-op render extension interface > replacement module if xrender is not found, > set the xrender_format to NULL, > and let the existing code do the trick? > > Would you like this better? I've thought about that before too. Yes, I think it's a much more maintainable approach. Probably put those stuff in a cairo-xrender-stub-private.h and be done. I've done this now. It can be found in the no-xrender.h branch in my new tree: git+ssh://annarchy.freedesktop.org/~behdad/public_html/cairo.git git://annarchy.freedesktop.org/~behdad/cairo.git I expect it to land soonish. (In reply to comment #11) > It can be found in the no-xrender.h branch in my new tree: > > git+ssh://annarchy.freedesktop.org/~behdad/public_html/cairo.git > git://annarchy.freedesktop.org/~behdad/cairo.git > > > I expect it to land soonish. > I was almost done :) I'll take a look at your changes. (In reply to comment #12) > (In reply to comment #11) > > It can be found in the no-xrender.h branch in my new tree: > > > > git+ssh://annarchy.freedesktop.org/~behdad/public_html/cairo.git > > git://annarchy.freedesktop.org/~behdad/cairo.git > > > > > > I expect it to land soonish. > > > > I was almost done :) > I'll take a look at your changes. Sorry about that. It seemed so easy that I just did it :). Created attachment 11366 [details] [review] patch (In reply to comment #14) > Created an attachment (id=11366) [details] > patch > thanks for the patch, I was not able to get your tree with git. It works; the only thing I did differently was that I did not do a special case for cairo_xlib_surface_create_with_xrender_format (whose implementation you included in ifdefs), since if you pass a XRenderPictFormat *format NULL it behaves fine. Anyway, I think you can close this. Thanks, Claudio (In reply to comment #15) > (In reply to comment #14) > > Created an attachment (id=11366) [details] [details] > > patch > > > > thanks for the patch, I was not able to get your tree with git. > It works; the only thing I did differently was that I did not do > a special case for cairo_xlib_surface_create_with_xrender_format > (whose implementation you included in ifdefs), > since if you pass a XRenderPictFormat *format NULL it behaves fine. We don't want the cairo_xlib_surface_create_with_xrender_format() symbol in the library. > Anyway, I think you can close this. Will do after I merge this. > Thanks, > > Claudio > Updated my branch, adding copyright/license info for the copied files. In master now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.