[cairo] CAIROMM: surfaces

[Jonathon Jongsma]

On 1/11/06, Murray Cumming <murrayc at murrayc.com> wrote:
> I'm not sure that it makes sense to have platform-specific surfaces. Do
> they offer any platform-specific API? Would any App ever need to
> distinguish between 2 platform-specific surfaces that it had?

But how would the app create the two different platform-specific
surfaces in the first place?  With the current arrangement, the only
surface type that can be created in cairomm is the default image
surface.  There's no way to (for example) create a glitz surface in
cairomm so that you can do GL-accelerated drawing.  The only way to do
this is revert back to C cairo and call cairo_glitz_surface_create()
and then wrap this with the Surface constructor that takes a
cairo_surface_t* argument).  This seems suboptimal to me.

The platform-specific surfaces may not have much platform-specific API
that distinguishes them (although there are some API differences), but
they all have different cairo 'constructor'  functions that take
different arguments (e.g. cairo_glitz_surface_create(),
cairo_pdf_surface_create(), etc). So I suppose that we could add a
whole bunch of overloaded static create() methods within the existing
Surface class that take different arguments and call different cairo
functions based on which create function was called.  The problem with
this is that there's no way to differentiate between some of the
surfaces based solely on construction arguments (for example,
constructors for pdf, ps, and svg surfaces all take arguments of
(const char*, double, double)).

So here's a quick overview of the differences in the surface types:
- image: has API for get_width and get_height (Are these inherited by
all other surfaces too? I can't tell)
- win32: adds some win32-specific font-related API
- xlib: adds set_size() and set_drawable() API
- ps, pdf, svg: all have same API (set_dpi) and construction arguments
but IMO they can't be combined into one type.  Apps need to be able to
create a specific one of these since they produce different output.
- glitz: no additional API
- quartz: no additional API
- beos: no additional API

Granted, most of these backends are still in an experimental state at
this point, but I think it's prudent to plan for a point when they are
supported so that the API doesn't change too drastically when this
happens.  So my opinion is that a class heirarchy is a good way to
provide the ability to create all of these surface types in cairomm
without reverting to plain cairo.

Thoughts?

> > Does anyone have problems with this, or opinions on how this should be
> > implemented in the C++ bindings?
>
> After asking about this
> ( http://lists.freedesktop.org/archives/cairo/2005-December/005818.html )
> I had thought that it wasn't necessary, but maybe the Pdf and Ps
> surfaces make it meaningful.

It looks like SVG should be added to this group as well, though I
don't know how mature it is.

Jonner