Re: _cairo_win32_display_surface_map_to_image issue

Hi Uli,

Thanks for the reply, it's very helpful. I' ll double check the bits
you are talking about asap. Just for the record, a simple code snippet
is available in this post to easily reproduce the problem on windows:
http://lists.cairographics.org/archives/cairo/2012-November/023728.html

The function may indeed be fed by bogus data, and that's exaclty what
I am trying to find out, with my little knowledge of the library:
where and how is the data somehow corrupted?

Regards,

Fred.

On Wed, Nov 14, 2012 at 3:47 PM, Uli Schlachter <[email protected]> wrote:
> 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
> --
> cairo mailing list
> [email protected]
> http://lists.cairographics.org/mailman/listinfo/cairo
-- 
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo