The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd replicated a bug from last time we did a copy optimization, and didn't get rendercheck run on it. This is effectively a re-cherry-pick of 510c8605641803f1f5b5d2de6d3bb422b148e0e7.
Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4 v2: Drop excessive src->depth == dst->depth check that snuck in. Signed-off-by: Eric Anholt <[email protected]> --- Michel, I didn't apply your review becuase you said "second clause", but I removed the first of the two. glamor/glamor_render.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index c590580412c9..b5903acb20c2 100644 --- a/glamor/glamor_render.c +++ b/glamor/glamor_render.c @@ -1423,6 +1423,11 @@ glamor_composite_clipped_region(CARD8 op, /* Is the composite operation equivalent to a copy? */ if (!mask && !source->alphaMap && !dest->alphaMap && source->pDrawable && !source->transform + /* We can't do direct copies between different depths at 16bpp + * because r,g,b are allocated to different bits. + */ + && !(dest->pDrawable->bitsPerPixel == 16 && + dest->pDrawable->depth != source->pDrawable->depth) && ((op == PictOpSrc && (source->format == dest->format || (PICT_FORMAT_COLOR(dest->format) -- 2.9.3 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
