[PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little
Keith Packard
keithp at keithp.com
Mon Oct 3 22:34:55 UTC 2016
Adam Jackson <ajax at redhat.com> writes:
> On Fri, 2016-09-30 at 22:44 -0700, Keith Packard wrote:
>
>> + /* copy mode for the first plane to clear all of the other bits */
>> + gcv[0].val = GXcopy;
>> + gcv[1].val = gc->fgPixel;
>> + gcv[2].val = gc->bgPixel;
>> + ChangeGC(NullClient, temp_gc, GCFunction|GCForeground|GCBackground, gcv);
>
> You don't need to set GCFunction here, the scratch gc already has
> GXcopy set.
>
> You _do_ need to copy GCPlanemask from the source gc, because for
> XYPixmap PutImage that determines how many planes of data were given;
> if you let it stay as FB_ALLONES when it should only be, say, 0x3,
> you'll read in 30 planes of garbage.
That's true for GetImage, but the protocol doc is rather unclear about
PutImage. The only mention of 'plane-mask' in the PutImage spec is as a
relevant component in the GC. Xlib doesn't look at the plane mask; the
request length is computed with:
bytes_per_dest = (unsigned long)ROUNDUP((long)req->width + req->leftPad,
dpy->bitmap_pad) >> 3;
bytes_per_dest_plane = bytes_per_dest * req->height;
length = bytes_per_dest_plane * image->depth;
req->length += (length + 3) >> 2;
Looks like fb has a bug.
--
-keith
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20161003/d6495b8b/attachment.sig>
More information about the xorg-devel
mailing list