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

Signed-off-by: Eric Anholt <e...@anholt.net>
---
 glamor/glamor_render.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c
index c590580412c9..26dee05b5ce1 100644
--- a/glamor/glamor_render.c
+++ b/glamor/glamor_render.c
@@ -1423,6 +1423,12 @@ glamor_composite_clipped_region(CARD8 op,
     /* Is the composite operation equivalent to a copy? */
     if (!mask && !source->alphaMap && !dest->alphaMap
         && source->pDrawable && !source->transform
+        && source->pDrawable->depth == dest->pDrawable->depth
+        /* 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

_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to