The copy optimization in d37329cba42fa8e72fe4be8a7be18e512268b5bd replicated a bug from last time we did a copy optimization: CopyArea is only defined for matching depths. This is only a problem at 15 vs 16bpp right now (24 vs 32 would also have matching Render formats but they should work) but be strict in case we store other bpps differently in the future.
Fixes rendercheck -t blend -o src -f x4r4g4b4,x3r4g4b4 v2: Drop excessive src->depth == dst->depth check that snuck in. v3: Switch back to src->depth == dst->depth Signed-off-by: Eric Anholt <[email protected]> --- glamor/glamor_render.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index a06868e3fdaa..d4d69a695d4d 100644 --- a/glamor/glamor_render.c +++ b/glamor/glamor_render.c @@ -1423,6 +1423,8 @@ glamor_composite_clipped_region(CARD8 op, /* Is the composite operation equivalent to a copy? */ if (!mask && !source->alphaMap && !dest->alphaMap && source->pDrawable && !source->transform + /* CopyArea is only defined with matching depths. */ + && 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
