[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).
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.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
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"
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.