[cairo] _cairo_win32_display_surface_map_to_image issue

[Uli Schlachter]

Hi,

On 13.11.2012 17:27, Fred bca21 wrote:
> while trying to fix a cairo crash on win32 (already posted on this
> list), I am trying to understand the function below, and I can't
> figure out how it works regarding coordinates (it looks inconsistent
> to me):

First: We are in _cairo_win32_display_surface_map_to_image(). That wasn't 
enirely clear to me from your mail.

> - The first call to  _cairo_win32_display_surface_create_for_dc
> creates a surface with the appropriate with and height regarding the
> extent rectangle.

The extent rectangle of the win32 surface that we are looking at. So this 
creates a surface of the same size as the already-existing surface that we are 
working with.

> - then why does the BitBlt call uses 0.0 as the origin for the source
> surface and not the origin of the extent since the newly created
> surface is supposed to represent the extent rectangle?

A surface doesn't really have any origin which would matter here. This code 
looks like it wants to copy the whole win32 surface to the newly created surface 
created above. Thus, source and destination offset are both 0, 0.

Nothing touched the 'extents' argument of 
_cairo_win32_display_surface_map_to_image() yet.

> - Also, why does the _cairo_image_surface_map_to_image using our newly
> created image does not use (0,0) as the origin, since our newly
> created image's origin corresponds to (extents.x,extents.y) in the
> original surface?

No, see above. The newly creates surface is as large as the original surface. 
Nothing touched the "extents" argument yet.

> There is probaby something that I am missing, but this seems to be the
> origin of the crash that I am chasing (this functions returns a
> pointer outside of the image boundaries due to a wrong offset).

Could you give us some examples of the width, height, rowstrides, formats and 
arguments for map_to_image used?

I am fairly sure that the image surface's map_to_image() works correctly. So if 
this returns bogous pointers, then the image surface must have been fed with 
bogous data.

> Thanks for your help.

One last idea: Do any of the involved surfaces have offsets applied? What is 
their surface->device_transform? Is it all zero.

Cheers,
Uli