Re: Image-Data upload using SHM

On Thu, Oct 20, 2011 at 11:53:18AM +0200, Clemens Eisserer wrote:
> On Thu, Oct 20, 2011 at 10:46:09AM +0100, Chris Wilson wrote:
> > On Thu, Oct 20, 2011 at 11:08:35AM +0200, Clemens Eisserer wrote:
> > > I did some profiling of Firefox's html5 video element which uses
> > > cairo, and the low performance I observed seems to be caused by not
> > > using XShmPutImage for uploading video-data.
> > > Instead, XPutImage is used - with xcb's 16kb buffer this results in
> > > about ~25k cs/s, slowing my machine down to a crawl.
> > ...
> > Why is xcb not using a BigReq anyway?
> 
> As far as I know, xcb does use BigReq.
> I am not an expert at such a low-level, but from my understanding xcb
> allocates a fixed-size 16kb buffer,
> and when writing more data than those 16kb, it has to flush the
> output-buffer - so the x-server can consume the data.
> At least that would explain the 25k context switches per second I am
> experiencing.

In your tests, are the requests going through Xlib's XPutImage, or XCB's
xcb_put_image?

If through Xlib: XPutImage does not use big-requests. I recently
closed-WONTFIX a 2004 bug report on the subject, with my understanding
of the situation; but as I note there, patches welcome.

https://bugs.freedesktop.org/show_bug.cgi?id=554

In the Xlib case, XCB's buffer size is irrelevant. Xlib's buffer, which
is managed just like it was before XCB, gets written directly to the
socket using XCB's socket sharing API (xcb_take_socket and xcb_writev).

If directly through XCB: xcb_put_image will happily use big-requests.
Also, if the image data exceeds the size of XCB's buffer, then the
existing buffer contents and the whole image data are written together
in a single writev system call.

In either case I think your performance problems are not my fault. ;-)

Jamey

--
cairo mailing list
[email protected]
http://lists.cairographics.org/mailman/listinfo/cairo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk6gOkMACgkQp1aplQ4I9mV63ACghZd097/kt7zWQuoTL7rGBXf/
9+4An1xumjL//75V+mksIq+YtroMFhrG
=2t4w
-----END PGP SIGNATURE-----