[cairo] [cairo-commit] src/cairo-image-compositor.c
ilia.softway at gmail.com
Sat Dec 6 15:45:41 PST 2014
Sorry, this hack was not intended to be a fix. I needed it to make our
software run and e-mailing it was an improper way to describe that the
assumption of the code on the ascending order of the scans fails.
After adding the following code at the beginning of cell_list_alloc
if (cells->head.next != &cells->tail && x < tail->x)
I found out that the function cell_list_find_pair
(cairo-tor-scan-converter.c) breaks the order because cells->cursor from
the previous call points to the value which exceeds x1 of the actual call.
I do not know the details of the scan generation algorithm, so not sure how
it was intended to be used, but if cells->cursor is a cached iterator
helping to find the proper position of the overlapping row slices in the
ascending order, I would expect that it should be set to pair.cell1 instead
of pair.cell2 at the end of cell_list_find_pair.
With best regards,
On 6 December 2014 at 13:12, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Fri, Dec 05, 2014 at 07:16:46PM -0800, Bryce Harrington wrote:
> > src/cairo-image-compositor.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> > New commits:
> > commit 5c82d91a5e15d29b1489dcb413b24ee7fdf59934
> > Author: Bryce Harrington <bryce at osg.samsung.com>
> > Date: Wed Dec 3 19:28:15 2014 -0800
> > image: Fix crash in _fill_xrgb32_lerp_opaque_spans
> > If a span length is negative don't go out of bounds processing the
> > data.
> This is a bogus patch. The root cause is that span lengths can not be
> negactive. Please revert and fix this properly, that will then fix all
> Chris Wilson, Intel Open Source Technology Centre
> cairo mailing list
> cairo at cairographics.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo