Bug 46255 - Image Surface _cairo_image_surface_paint() has logic issue
Summary: Image Surface _cairo_image_surface_paint() has logic issue
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: image backend (show other bugs)
Version: 1.10.2
Hardware: All All
: medium major
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-18 10:04 UTC by Hao
Modified: 2012-04-03 07:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
cairo-trace of the issue (8.28 KB, application/octet-stream)
2012-02-20 00:10 UTC, Hao
Details
Correct result (3.81 KB, image/png)
2012-02-20 00:11 UTC, Hao
Details
Incorrect result when render to the image surface (7.31 KB, image/png)
2012-02-20 00:12 UTC, Hao
Details

Description Hao 2012-02-18 10:04:02 UTC
The issue is the image surface will have different rendering result than the xlib surface. 

e.g. If a circle should get clipped by a clip. On xlib surface, everything draws fine. On image surface, the circle is NOT clipped.



http://cgit.freedesktop.org/cairo/tree/src/cairo-image-surface.c?h=1.10

Under _cairo_image_surface_paint(), there are two issues:

1. line 3294 -> 3302. Logic of "(clip_path = _clip_get_single_path (clip)) != NULL)" is not correct. It just simple against the comment above that logic. Since this will still be a valid condition even when the clip contains a set of boxes.

The same code path in _cairo_surface_fallback_paint() in cairo-surface-fallback.c should be the correct logic (line 918): "clip != NULL && clip_path->prev == NULL"


2. The _clip_get_single_path() in the cairo-image-surface.c, at line 3243, the return value shouldn't be "FALSE" anyway. It should be a (cairo_clip_path_t *) value, not boolean. I suspect, it should be "path" instead.


SAME ISSUEs in cairo-xcb-surface-render.c as well.
Comment 1 Uli Schlachter 2012-02-19 10:28:31 UTC
Do you have any self-contained test case which show the issue? Does the problem happen with the git master version of cairo, too?
The function _clip_get_single_path() doesn't exist in master any more.
Comment 2 Hao 2012-02-20 00:10:05 UTC
Created attachment 57298 [details]
cairo-trace of the issue
Comment 3 Hao 2012-02-20 00:11:46 UTC
Created attachment 57299 [details]
Correct result

Rendering result of following HTML page:

<body>
<iframe src="simple.svg" style="border: 1px solid red; width: 100px; height: 100px;"></iframe>
</body>

with the content of simple.svg to be following:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1">
<circle cx="100" cy="100" r="100" />
</svg>
Comment 4 Hao 2012-02-20 00:12:15 UTC
Created attachment 57300 [details]
Incorrect result when render to the image surface
Comment 5 Hao 2012-02-20 00:13:17 UTC
Hi, Uli,

1. Self-contained test case
Yes. But it's a relatively complicate one. It happens when I'm rendering a simple web page in WebKitGTK, which uses cairo.
(There is a circle SVG image inside an iframe, which is marked by the red box, so the circle should be clipped)
What I observed:

xlib surface, no matter which cairo version.OR image surface, with version 1.9.4 and before (e.g. 1.8.10)
The result is 
webViewSurface_correct.png


image surface, with version after 1.9.8 (e.g. 1.10.2)
The result is
webViewSurface_error.png

I have the cairo-trace log for just paint to the image surface as attached "simple.trace"

2. Git Master version?
I didn't try git master version, but by looking at the code, I don't think it will. Since the _cairo_image_surface_paint() simply calls _cairo_compositor_paint(), which is shared by many surfaces.
If this happens, it must be spot by somebody already.

Hao
Comment 6 Hao 2012-02-20 00:20:00 UTC
Just tried the latest git. And it renders correctly in the image surface as expected.
Comment 7 Chris Wilson 2012-04-03 07:24:59 UTC
Stable release with bug-fix, so closing even if I haven't identified the exact fix.


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.