Bug 554

Summary:	RFE: Investigate whether libX11's XPutImage() code can use the BIGREQUESTS extension
Product:	xorg	Reporter:	Roland Mainz <roland.mainz>
Component:	Lib/Xlib	Assignee:	Jamey Sharp <jamey>
Status:	RESOLVED WONTFIX	QA Contact:	Xorg Project Team <xorg-team>
Severity:	enhancement
Priority:	high	CC:	ajax, alan.coopersmith, boiko, jeremyhu
Version:	git
Hardware:	All
OS:	All
Whiteboard:	2011BRB_Reviewed
i915 platform:		i915 features:

Description Roland Mainz 2004-04-26 07:44:10 UTC

[Based on an ealier discussion with Alan]
RFE: Investigate whether libX11's XPutImage() code can use the BIGREQUESTS
extension.

It seems that the current version of libX11's XPutImage() code does not use the
BIGREQUESTS extension which may result in huge performance problems for large
image blits. The problem is that XPutImage() requests which are too large will
be split into smaller requests - which ends in a sequence of malloc() calls and
the image data are copied multiple times.

The solution for this would be to check whether it is possible to use the
BIGREQUESTS extension for image data to avoid such problems (if this breaks
somehow compatibility to existing applications it may be even worth to bump the
BIGREQUESTS extension version and only use XPutImage()-over-BIGREQUESTS if both
server and client version are at least at the new version level).

Comment 1 Adam Jackson 2005-11-19 08:43:51 UTC

this probably would be a win.  experimentally, x11perf of plain XPutImage shows
effective bandwidth highest at 100x100, so it appears that 500x500 exceeding the
smallrequest size does indeed hurt.  XShmPutImage does not show this
degradation, with performance approaching a limit on successively larger images.

it's worth noting that almost all toolkits will upgrade to XShmPutImage behind
the scenes if possible, so the win reduces to those situations where MIT-SHM is
unavailable.  which means, over the network, and those DDXes that don't support
MIT-SHM.

Comment 2 Daniel Stone 2007-02-27 01:23:28 UTC

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Comment 3 Jeremy Huddleston Sequoia 2011-09-25 15:47:09 UTC

I wonder if this is still worth doing in Xlib.

Jamey, how does xcb do its version of PutImage?  Maybe we should just close 
this as "use xcb instead"

Comment 4 Jamey Sharp 2011-09-25 16:16:27 UTC

I remember having been confused when I discovered that XPutImage didn't use big requests. As I recall, I came away with the conclusion that the original authors were concerned that the big PutImage requests would monopolize the server for excessive periods, since the server is single-threaded. Perhaps image blits are fast enough these days that nobody needs to care?

Xlib does need to support image splitting, though, even if it were to use BIG-REQUESTS, because there's still a maximum request size; it just typically increases from 256kB to 16MB.

XCB's protocol stubs intentionally don't do anything clever, so if you pass a big image to xcb_put_image then it will have to use the BIG-REQUESTS extension. If you pass an image that's too big for the server's maximum request size then XCB will shut down your connection and return an error.

If you use the util-image library instead, it looks to me like nobody has implemented request-splitting there either, so xcb_image_put has the same behavior as xcb_put_image, which is probably a bug. But as long as your images are smaller than 16MB (uncompressed) you won't notice...

I'm marking this WONTFIX because it seems hardly important to me, but hey, anybody who wants to hack on Xlib is welcome to.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.