[cairo] CAIROMM: surfaces

[Murray Cumming]

On Wed, 2006-01-11 at 13:34 -0600, Jonathon Jongsma wrote:
> 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().

Yes, that makes sense. But is cairo_win32_surface_create() really
declared and defined in cairo on linux?

How is an xlib surface different than an Image surface? Why isn't there
a cairo_platform_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.

Yes.

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

I am convinced, though I'd like the documentation to say when you'd want
to use each class.

-- 
Murray Cumming
murrayc at murrayc.com
www.murrayc.com
www.openismus.com