[PATCH] dix/dispatch: DoGetImage: Use a single buffer

[Keith Packard]

Mark Kettenis <mark.kettenis at xs4all.nl> writes:

> Heh, I just happened to be in there yesterday.  The memmove'ing gets
> incredibly insane if you're trying to move a large image through a
> socket with a small socket buffer size (like the 4k that was passed
> down to us by the CSRG).  A typical 8-megapixel image produced by a
> digital camera takes tens of seconds when you send it in 4k chunks and
> memove the remainder of the image after each chunk with CPU usage by
> Xorg going through the roof.

GetImage just wasn't a big concern when the current output code was
written; before that, it was pulling chunks off the frame buffer and
blocking on the write sending them to the client without any additional
copies.

> Your ReserveOutputSpace() idea would certainly help here as it would
> eliminate or at least reduce the overhead of resizing the circular
> buffer.  Would Daniel's diff have the same effect?

For the most part, yes. Daniel's patch will eliminate reallocating the
output buffer for each chunk from the image. My idea would simply avoid
doing the copy from the temporary GetImage buffer into the output
buffer.

> I ended up modifying libxtrans to set the socket buffer size to
> something 64k to fix the performance problem I was investigating.  See
> the diff below.  I guess most Linux uses a larger default socket
> buffer size, in which case the performance problem might not be so
> prominent.

Yeah, local linux sockets use a much larger buffer, but I don't know
what that size is.

> In my case the problem shows up with Firefox, which apparently is
> rendering images to the screen when downloading them, then grabs the
> pixels with XGetImage() and re-renders using those grabbed pixels.
> Seems utterly retarded to me, and it is potentially an issue with the
> old cairo embedded by Firefox.

Sounds like we might actually want to fix this then.

You might  try the combination of your changes with Daniel's patch and
see what you get; doing the whole GetImage in a single WriteToClient
should help a bunch, especially when mixed with your change.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140329/b0069d86/attachment.sig>