Re: [PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

Adam Jackson writes: > Formerly we'd zero the image data and then pull out a plane at a time. > It's faster to apply the planemask after the fact, since that turns the > GetImage into a memcpy: > > 10.0 101000.0 (1.010) (copy 0x) ShmGetImage 10x10 square >

Re: [PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

Adam Jackson writes: > I have a plan to deal with 24bpp, very harshly indeed. You know how much time I spent writing that code. You're deleting some of the "finest" bitblt in the server. > You do appear to be correct though, xfree86 still has paths by which > you can ask for a

Re: [PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

On Wed, 2016-09-28 at 10:19 -0700, Keith Packard wrote: > You'll need to deal with 24bpp separately... I have a plan to deal with 24bpp, very harshly indeed. You do appear to be correct though, xfree86 still has paths by which you can ask for a 24bpp pixmap/wire format, so I can't assume we'll

Re: [PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

Adam Jackson writes: > diff --git a/fb/fbimage.c b/fb/fbimage.c > index 59daa21..8f5f3dc 100644 > --- a/fb/fbimage.c > +++ b/fb/fbimage.c > @@ -250,13 +250,16 @@ fbGetImage(DrawablePtr pDrawable, > > pm = fbReplicatePixel(planeMask, srcBpp); > dstStride =

[PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

Formerly we'd zero the image data and then pull out a plane at a time. It's faster to apply the planemask after the fact, since that turns the GetImage into a memcpy: 10.0 101000.0 (1.010) (copy 0x) ShmGetImage 10x10 square 42400.0 59400.0 (1.401) (copy 0x) ShmGetImage