Bug 5816 - Image surfaces do not start out blank by default
Summary: Image surfaces do not start out blank by default
Status: RESOLVED FIXED
Alias: None
Product: cairo
Classification: Unclassified
Component: png functions (show other bugs)
Version: 1.1.1
Hardware: x86 (IA32) All
: high critical
Assignee: Carl Worth
QA Contact: cairo-bugs mailing list
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2006-02-06 04:51 UTC by Dom Lachowicz
Modified: 2006-04-14 16:35 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Dom Lachowicz 2006-02-06 04:51:55 UTC
Please see librsvg bug http://bugzilla.gnome.org/show_bug.cgi?id=323114,
especially comment #12, which I will copy here. I'd be ok with
FbPixelsCreateForData not to do this initialization since you can presume it's
been done already at a higher level. Or, alternately, make them both zero out
the pixels for consistency's sake.

While librsvg creates an image surface from its
own zeroed-out data when it calls cairo_image_surface_create_for_data() (the
rsvg-view case), cairo does not do the same when in
cairo_image_surface_create() (the rsvg-convert case). It may be that cairo
expects us to call CAIRO_OPERATOR_CLEAR on the surface, but I contend that
necessity is bogus, since the presumption should be "you get a blank surface by
default", not "you get an undefined, probably corrupt surface by default". The
following patch to cairo/pixman/src/icpixels.c fixes the problem.

Index: pixman/src/icpixels.c
===================================================================
RCS file: /cvs/cairo/cairo/pixman/src/icpixels.c,v
retrieving revision 1.9
diff -u -p -u -r1.9 icpixels.c
--- pixman/src/icpixels.c       25 Jun 2005 03:13:19 -0000      1.9
+++ pixman/src/icpixels.c       5 Feb 2006 17:49:34 -0000
@@ -72,6 +72,7 @@ FbPixelsCreate (int width, int height, i
        return NULL;

     buf = (pixman_bits_t *) ((char *)pixels + base + adjust);
+    memset(buf, 0, height * stride);

     FbPixelsInit (pixels, buf, width, height, depth, bpp, stride);
Comment 1 Dom Lachowicz 2006-02-06 06:18:32 UTC
I'm weary that the solution I'll be told (and the workaround already posted in
that librsvg bug) is "use CAIRO_OPERATOR_CLEAR and cairo_paint(). But I'd like
to preempt that if possible. I think that the metaphor cairo should follow is as
follows:

An artist asks her friend for a sheet of paper to draw on. At this point, the
friend can do one of two things:

1) Give the artist back a clean sheet of paper (zero the pixels by default)
2) Give the artist back a piece of paper with complete with scribbles done by
her 2-year old daughter, and a bottle of white out (CAIRO_OPERATOR_CLEAR,
cairo_paint()). Caveat emptor.

I think if this is an appropriate analogy, #1 is clearly correct and #2 would
(deservedly) get a blank stare from the artist.
Comment 2 Carl Worth 2006-04-15 09:35:11 UTC
Dom,

You win. That behavior was really annoying.

I've just committed a change to 1.1.1 to fix this, and I mailed out to the cairo
list asking for any objections:

http://lists.freedesktop.org/archives/cairo/2006-April/006692.html

If anyone has any compelling objections, we can re-open this. But for now, it is
closed.

-Carl

PS. And thanks for the patch!


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.