[cairo] cairo_win32_surface_create api change

[Vladimir Vukicevic]

There's a number of problems here... the windows (and quartz, I guess)
surfaces use a different API from the X11 surface creation methods. 
The X11 surface creation methods all take some kind of Drawable or
Pixmap, along with a width and height.  However, the windows function
takes an HDC, which is analogous to a X11 GC, which causes the
problems Stuart describes.  The mac surface takes a CGContextRef, but
it also takes an associated width and height.

This is a pretty interesting inconsistency in the API; on windows and
quartz, the initial HDC/CGContextRef state can affect drawing in ways
that cairo knows nothing about.  It seems that we may want to lean
towards the X11 style of doing things for future surfaces; that is,
create the surface from the actual thing that you're drawing to,
rather than some kind of structure that you would use with the native
API to draw onto the thing. (e.g., Window and not GC).

I'd suggest that we take stuart's patch that adds width/height for
both API consistency and less potential for developer surprise -- the
initial state of the HDC will affect drawing to the surface, and that
can have unexpected results as fallbacks are hit (that only know about
the cairo state, and not the HDC state).  We can leave the old method
in, take it out of the public header file and document it as obsolete.

We should also consider adding methods for creating a surface from a
HWND, etc. for API consistency purposes.

    - Vlad

On 12/5/05, Stuart Parmenter <stuartp at gmail.com> wrote:
> On 12/2/05, Owen Taylor <otaylor at redhat.com> wrote:
> > On Thu, 2005-12-01 at 14:54 -0800, Stuart Parmenter wrote:
> > > Here is my patch.
> > >
> > > The things "set up so that the width/height *are not* necessary" are
> > > broken it turns out.  You are using the clipbox as the width/height of
> > > the surface which will almost always be wrong if you're using
> > > clipping. Backend functions such as get_extents need to actually
> > > return the proper values for things to work.  Both of these tests hit
> > > code paths that use get_extents after setting the clip region to null
> > > resulting in a 0,0,0,0 return from get_extents which ends up clipping
> > > out lots of stuff, which isn't really what you want.
> >
> > Without an actual description of the code paths that aren't working,
> > it's hard for me to propose the correct fix, but the extents of a
> > DIB or DDB are determinable without extra API and on general grounds
> > having a drawing operation depend on the extents of a window almost
> > certainly indicates that something is wrong.
> >
> > Regards,
> >                                                 Owen
>
>
> I noticed that I only sent this to Owen previously.  Resending to list.
>
> Run the tests I said previously and put some break points in
> _cairo_win32_surface_get_extents and then see what happens when you
> get 0,0,0,0 returned.  Or simply grep for cairo_surface_get_extents
> and look at all the callers.
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://cairographics.org/cgi-bin/mailman/listinfo/cairo
>