[Freeciv-Dev] (PR#15055) RFC: Cairo to replace the canvas functions

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=15055 >

OK, it's time to revisit this idea.

The concept is simple: we get rid of all canvas and sprite functions, 
and replace them with cairo_t and cairo_surface_t functions (how 
coincidental that we independently invented almost the exact same system!).


Question #1: How would you go about such a thing?

Answer: For the client common code, we have to replace all users of the 
canvas and sprite functions with cairo users.  This shouldn't be that 
hard, except for places where the APIs don't line up exactly.

Meanwhile the GUIs will have to write some glue code to obtain cairo_t 
and cairo_surface_t objects instead of canvases and sprites:

- For gui-gtk-2.0 it should be easy; we just use gdkcairo (#include 
<gdk/gdkcairo.h>).  In the ideal case gdkcairo will take care of setting 
up the appropriate cairo backend for us, so eventually we'll be using 
opengl automatically.

- For gui-xaw it should also be fairly easy since cairo has an xlib 
backend.  Some glue is needed since cairo assumes xrender and alpha 
support, whereas current gui-xaw uses Pixmaps and Bitmaps.  More code 
would be needed to integrate opengl support.  This can/should probably 
be separated into a library.

- For gui-win32 it should be fairly easy since cairo has a GDI backend. 
  Pretty much the same as gui-xaw (see above).

- For gui-sdl it may be harder.  What's needed is a sdlcairo library 
corresponding to the gdkcairo one.  Hopefully such a thing exists; if 
not it really should.


Question #2: Why would we want to do such a thing?

Answer: Well, naturally there are advantages and disadvantages.

- It's a lot of work.

- It might make things slower since cairo has client-side software 
rendering (pretty much like the hated gdkpixbuf) as its fallback, and is 
not yet well optimized.

- Potentially buggy and non-portable.  Cairo is a very young library. 
However it is very actively maintained (unlike some libraries I can 
mention) since it is the backend for GTK/GDK on which a vast amount of 
production-level OSS depends.

- It gives us scaling "for free".  Well, it might be slower (depending 
on the rendering backend), but it should only take one line of code in 
the drawing section to do scaling.

- A lot of code (all the canvas and sprite functions) go away.

- Better results for some backends.  For instance gui-xaw would get 
anti-aliased text and alpha support.  gui-win32 under win98 probably 
would too.  gui-gtk would get anti-aliased versions of many functions 
(like canvas_put_line).

- More consistent results across backends.  Cairo is designed to give 
identical results for all backends...just like our sprite/canvas 
interface is, but of course cairo is a bit better at it.

- Potential hardware acceleration.  Cairo is designed specifically with 
backend hardware acceleration (through opengl/glitz) in mind.  Support 
for this is very weak at the moment, but becuase cairo is actively 
maintained and soon to be put into production use I doubt it will remain 
so.  Once the glitz backend is effectively working and well-supported, 
we could get hardware acceleration *for free* in the gtk backend, or 
with a minimum of extra glue in the other backends.


Question #3: Who's going to do the work?

- I will patch the core code and gtk client.

- All the GUI maintainers will have to update their clients.


Question #4: When will this happen?

- Not until GTK 2.8 is widely distributed.

- Which is to say, probably for 2.2.


-jason