Bug 6170 - Invalid CAIRO_OPERATOR_XOR results in xlib surface
Summary: Invalid CAIRO_OPERATOR_XOR results in xlib surface
Status: RESOLVED NOTABUG
Alias: None
Product: cairo
Classification: Unclassified
Component: xlib backend (show other bugs)
Version: 1.0.2
Hardware: Other Linux (All)
: high normal
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-07 20:56 UTC by Alexander Darovsky
Modified: 2006-03-09 07:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
operator xor in PNG backend (1.06 KB, image/png)
2006-03-07 20:57 UTC, Alexander Darovsky
Details
xlib results of the same snippet (977 bytes, image/png)
2006-03-07 21:01 UTC, Alexander Darovsky
Details

Description Alexander Darovsky 2006-03-07 20:56:59 UTC
Hi. 
Unfortunately, png and xlib backends handle XOR operator in different ways. 
 
Here is an example (from cairo_snippets) 
 
snippet_normalize (cr, width, height); 
cairo_set_operator (cr, CAIRO_OPERATOR_XOR); 
cairo_set_source_rgba (cr, 1,0,0, 0.5); 
cairo_rectangle (cr, 0.2,0.2, 0.5,0.5); 
cairo_fill (cr); 
cairo_set_source_rgb (cr, 0,1,0); 
cairo_rectangle (cr, 0.4,0.4, 0.4,0.4); 
cairo_fill (cr); 
cairo_set_source_rgb (cr, 0,0,1); 
cairo_rectangle (cr, 0.6,0.6, 0.3,0.3); 
cairo_fill (cr); 
 
Results are attached below.
Comment 1 Alexander Darovsky 2006-03-07 20:57:53 UTC
Created attachment 4854 [details]
operator xor in PNG backend
Comment 2 Alexander Darovsky 2006-03-07 21:01:30 UTC
Created attachment 4855 [details]
xlib results of the same snippet

here is how xlib backend handles operator XOR.
Maybe XRenderFillRects is buggy, but I see the same behavior with glitz
backend...
Comment 3 Alexander Darovsky 2006-03-07 21:06:48 UTC
In fact, results from OPERATOR_DEST_OUT and CAIRO_OPERATOR_XOR 
are identical. And both differ from PNG ones 
Comment 4 Owen Taylor 2006-03-08 00:31:10 UTC
Are you comparing surfaces with destination alpha to surfaces with 
destination alpha?
Comment 5 Alexander Darovsky 2006-03-08 20:02:53 UTC
Both surfaces are created with default parameters.  
XRender and glitz surfaces may have no destination alpha,  
but XOR operation still invalid: if I draw white square on  
black background result should be white square. But it does not...  
  
Pure Xlib works correctly in this case.  
Comment 6 Owen Taylor 2006-03-08 23:21:36 UTC
Note that XOR here is the Porter-Duff XOR operator, and is entirely different
from the Raster-Op XOR that you'd find in XLib.
Comment 7 Alexander Darovsky 2006-03-09 02:15:53 UTC
If it is not a bitwise XOR, then maybe it works properly... 
Maybe it have sense to highlight it in documentation somehow, 
to avoid such a questions, frequent, i think? 
Comment 8 Alexander Darovsky 2006-03-09 15:14:55 UTC
PS. Is there any way to get an old bitwise XOR in cairo? 
Comment 9 Carl Worth 2006-03-10 02:31:17 UTC
(In reply to comment #8)
> PS. Is there any way to get an old bitwise XOR in cairo? 

No.

A bitwise operation would not be well-defined in cairo. Many backends, (think
PostScript, PDF and SVG), do not have "bits" to be manipulated. So, at best,
this would have to be some backend-specific operation.

We don't like to put backend-specific drawing operations into cairo. If you
really need this, you can drop down to doing backend-specific drawing yourself
behind cairo's back, (for example, using Xlib to draw to the same drawable). If
you're going to do that, just call cairo_surface_flush when switching from cairo
to non-cairo drawing, and cairo_surface_mark_dirty before switching back).

-Carl


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.