[cairo] CAIROMM: surfaces

[Murray Cumming]

On Wed, 2006-01-11 at 10:33 -0600, Jonathon Jongsma wrote:
> 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

I'm suggesting that it couldn't, so this isn't something that we want to
expose in the API, and probably isn't something that cairo's C API wants
to expose in the API.

> ?  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.

Sure. I guess this should be wrapped like the hierarchy of pattern
classes, if application authors would have a reason to instantiate them.
Out of interest, when would I want to choose between accelerated and
non-accelerated surfaces?

There is one problem with both the pattern and surface hierarchies
though:
http://lists.freedesktop.org/archives/cairo/2005-December/005852.html

> 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)).

Yes, the Pattern classes have create functions.

> 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.

Maybe we can have some kind of base class for ps, pdf, and svg.

> - 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. 

If it's stable API in cairo then it should be stable API in cairomm, I
suppose. If it's not meant to be stable, then we can document it as
such.

Thanks for looking at this.

>  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
-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com