[cairo] cairo_win32_surface_create api change

[Stuart Parmenter]

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.

It also isn't going to always be the case that the clip rect that is
set on the window you pass in is really the width and height of the DC
that you're interested in which means that using it in the first place
will be wrong.

stuart

On 11/30/05, Owen Taylor <otaylor at redhat.com> wrote:
> On Tue, 2005-11-29 at 17:10 -0800, Stuart Parmenter wrote:
> > I would like to change the cairo_win32_surface_create to take a width
> > and height so that get_extents can function properly.  All of the
> > other surface creation functions take widths and heights.  We need to
> > do this to pass all the tests on Windows, specifically self-copy and
> > trap-clip.
> >
> > Carl brought up the issue of compatibility, but leaving the old API
> > there leaves us with pretty broken clipping on Windows.  This change
> > should be trivial for callers to fix and I don't know of any Windows
> > apps that actually use/ship with cairo at this point.
> >
> > We could leave the old API in and bandaid aorund it, but that seems
> > like a bad solution long term as it will only lead to people seeing
> > different strange problems later on and not being able to explain
> > them.
>
> I'd really like to see more explanation as to why you think this
> change is necessary. Quite a few things were set up so that the
> width/height *are not* necessary. Especially for trap-clip, if that's
> not working, it's probably just an implementation bug somewhere.
>
> The only justification for an incompatible change would be if major
> parts of the API simply don't work with the old change. And that seems
> unlikely since we have GTK+ running quite well on top of Cairo on
> Windows.
>
> Regards,
>                                                 Owen
>
>
>