[cairo] CAIROMM: surfaces

Jonathon Jongsma jonathon.jongsma at gmail.com
Wed Jan 11 11:34:40 PST 2006


On 1/11/06, Murray Cumming <murrayc at murrayc.com> wrote:
> On Wed, 2006-01-11 at 10:33 -0600, Jonathon Jongsma wrote:
> > 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.

To me it seems like it's essential to the API.  Take GTK+ for example.
 It determines which platform it's being compiled for and, for
unix/X11, it calls cairo_xlib_surface_create(), and for win32 it calls
cairo_win32_surface_create().  Without this functionality exposed in
the API, how could GTK+ use the proper surface for the platform
they're running on?  Or are you saying that this should be done
automatically inside the cairo library so that the app doesn't have to
worry about choosing the right platform-specific surface?  Maybe I'm
not understanding...

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

I'm not sure, but my opinion is that cairomm should provide a C++
wrapper around the full functionality of cairo unless there's a really
good reason to omit something.  And I don't see the need to deny
people the ability to create accelerated surfaces (or any other
surface type) if they want to, since that ability exists in cairo.

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

agreed.  then I'd propose something like the following:

- Surface
   - ImageSurface
   - FileSurface (name TBD)
      - PdfSurface
      - PsSurface
      -SvgSurface
   - XlibSurface
   - Win32Surface
   - GlitzSurface
   - etc.

Have I convinced you yet? :)  Anybody else have opinions on this?

Jonner


More information about the cairo mailing list