Bug 103614 - painting an xlib surface with source set to another surface created with cairo_image_surface_create_from_png fails if xlib surface is set to the exact size of the png image.
Summary: painting an xlib surface with source set to another surface created with cair...
Status: RESOLVED INVALID
Alias: None
Product: cairo
Classification: Unclassified
Component: png functions (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-08 00:32 UTC by Stefan
Modified: 2017-11-15 17:38 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
small C program showing the bug, look at tag 'bug #3' in the source for details. (3.63 KB, text/x-csrc)
2017-11-08 00:32 UTC, Stefan 		Details
View All

Description Stefan 2017-11-08 00:32:28 UTC 
Created attachment 135294 [details]
small C program showing the bug, look at tag 'bug #3' in the source for details.

I created a surface: 

   image = cairo_image_surface_create_from_png(argv[1]);
   x = cairo_image_surface_get_width (image);
   y = cairo_image_surface_get_height (image);

then i created an xlib surface and set the png surface as source for painting:

   sfc = cairo_xlib_surface_create(display, window, visual, x, y);
   cairo_xlib_surface_set_size(sfc, x, y);
   ctx = cairo_create(sfc);
   cairo_set_source_surface(ctx, image, 0., 0.); 

Painting the xlib: 

   cairo_paint(ctx);

fails (get only background of xlib window) unless i add one pixel to the
xlib surface:

cairo_xlib_surface_set_size(sfc, x+1, y);

This behavior happens on all debian linux machines i have access to,
but does NOT happen on a very old rhel5 server with a (much)older cairo revision.
Test program attached. I hope i am not doing something wrong, i checked the test case line by line and to me it seems correct.
Stefan
Comment 1 Uli Schlachter 2017-11-10 17:09:50 UTC 
For the bug you are reporting (bug #3): Call cairo_surface_flush(sfc) after your call to cairo_paint(ctx). The docs say this "[does] any pending drawing for the surface". 

Bug #2: Why is that a bug? You also get other events even when they are not in your event mask (e.g. MappingNotify). Cairo needs this extra event to avoid some possible unbounded memory usage problems which have to do with shared memory (basically, these events tell cairo that the X11 server is done accessing the shared memory).
Comment 2 Stefan 2017-11-13 14:35:31 UTC 
What are the limitations on coordinate system when working on image surfaces?
I guessed that (despite of double types) Cairo uses a 24.8 fixed point notation that should allow coordinates up to +/- 8M. However for image surfaces even a 
(-97000, -97000):(97000, 97000) line is not displayed.
Thank you for resolving my problem #3 !.
Stefan
Comment 3 Uli Schlachter 2017-11-15 17:38:30 UTC 
I took a quick look and something in cairo-tor-scan-converter.c seems to mishandle your line. I don't know the details, sorry.

This polygon is its input (I am rendering your line to a 20x20 image surface):

polygon: extents=(0.000000, 0.000000), (20.000000, 20.000000)
  [0] = [(0.000000, 0.000000), (0.000000, 20.000000)], top=0.000000, bottom=1.414062, dir=-1
  [1] = [(-200000.707031, -199999.292969), (199999.292969, 200000.707031)], top=1.414062, bottom=20.000000, dir=-1
  [2] = [(20.000000, 0.000000), (20.000000, 20.000000)], top=18.585938, bottom=20.000000, dir=1
  [3] = [(-199999.292969, -200000.707031), (200000.707031, 199999.292969)], top=0.000000, bottom=18.585938, dir=1

I am not quite sure, but this seems more or less okay. The scan converter then ends up with 0 spans most of the time, but just some spans on the last two lines.

So... no idea.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.