[cairo] cairo_win32_surface_create api change
otaylor at redhat.com
Thu Dec 8 10:34:11 PST 2005
On Thu, 2005-12-08 at 00:45 -0500, Owen Taylor wrote:
> I spent some time tracking down the problem with trap-clip.c on win32,
> and it wasn't really related to the win32 code at all.
> The issue in self-copy may be entirely different ... I haven't looked
> at it.
Looking at self-copy, the issue there is a lot more straightforward;
things are going wrong because of the fallback code's usage of
_cairo_pattern_get_extents (), which in turn calls
_cairo_surface_get_extents() ... in this case,
_cairo_surface_get_extents() is being used to mean "how big is the
image (when used as a source)" rather than "how big is the area that
needs to be drawn to.
My suggestion here would be to add another surface virtual function
_cairo_surface_get_source_extents() with that meaning.
But, you ask, how would the win32 surface know the size of the source
surface without API changes? it turns out we already have
a stored size: win32_surface->clip_rect that is used for that purpose -
This is initialized one of two ways:
- If we create the surface ourselves, we store the size in there
- If we create the surface from a DC, it's the value of GetClipBox()
before we do any clipping ourselves.
The latter version isn't perfect of course; if someone clips
the DC before passing it to us, then we'll be in trouble; but really,
the case where you have a DC that you want to use as a source
and you also have a clip on that DC seems pretty unlikely.
As long as the DC points to a bitmap, we can actually do better without
a lot of work, just use GetCurrentObject() to retrieve the bitmap
and GetObject() to find the bitmap's dimensions. (*)
(*) Note that using a window as a source is a bad idea for all the
normal reasons; to scroll a window you need to use CopyArea
with GraphicsExpose events turned on, ScrollWindowEx(),
or other similar functions that have an idea of an invalid
More information about the cairo