[cairo-bugs] [Bug 15349] bad clipping with EXTEND_NONE
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Apr 7 05:52:55 PDT 2008
http://bugs.freedesktop.org/show_bug.cgi?id=15349
--- Comment #6 from Owen Taylor <otaylor at redhat.com> 2008-04-07 05:52:51 PST ---
It's been pointed that what's currently in git is causing some rendering
artifacts:
http://people.mozilla.com/~vladimir/misc/broken.c
http://people.mozilla.com/~vladimir/misc/broken-xlib-rgb24-out.png
What's going on here is that with the current version,
_cairo_pattern_acquire_surface() is being called:
- with an integer translation or identity matrix
- with a bounds bigger than the source surface
I think this could happen previously, but only when
!_cairo_operator_bounded_by_source(op).
When the above two things are true, there's an obvious bug in
_cairo_pattern_acquire_surface_for_surface()
/* Otherwise, we first transform the rectangle to the
* coordinate space of the source surface so that we can
* clone only that portion of the surface that will be
* read. */
[...]
if (! _cairo_matrix_is_identity (&attr->matrix)) {
double x1 = x;
double y1 = y;
double x2 = x + width;
double y2 = y + height;
cairo_bool_t is_tight;
_cairo_matrix_transform_bounding_box (&attr->matrix,
&x1, &y1, &x2, &y2,
&is_tight);
/* The transform_bounding_box call may have resulted
* in a region larger than the surface, but we never
* want to clone more than the surface itself, (we
* know we're not repeating at this point due to the
* above.
*
* XXX: The one padding here is to account for filter
* radius. It's a workaround right now, until we get a
* proper fix. (see bug #10508)
*/
x = MAX (0, floor (x1) - 1);
y = MAX (0, floor (y1) - 1);
width = MIN (extents.width, ceil (x2) + 1) - x;
height = MIN (exts.height, ceil (y2) + 1) - y;
}
So the clamp to the bounds of the surface only occurs when the matrix
is not the identity.
With the patch in bug 15367 the problem won't be apparent because we
use the tight bounds on the source surface for the identity matrix, and
there will be no regression, but I think you can still have the
problem with other operations, so a separate tiny fix is probably more
appropriate.
I'll come up with a patch, test and attach here. There is a separate
problem with this function I noticed on inspection ... if x/y are
> 0 when we grab from the source surface, I think we'll draw
the wrong result since we make no adjustment for the partial source
surface. I'll file that separately.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the cairo-bugs
mailing list