"Maybe I'm just naive, but designing a graphics API such that all image data had to be sent over a socket to another process every time the image needed to be drawn seems like complete idiocy. Unfortunately, that is precisely what the X Window System forces a program to do, and exactly what Cairo does when drawing images in Linux - a full copy of the image data, send to another process, no less, every time it is drawn. One would think there would be some room for improvement. Unsurprisingly, others felt the same way about X, and decided to write an extension, Xlib Shm or XShm for short, that allows images to placed in a shared memory segment from which the X server reads which allows the program to avoid the memory copy. GTK already makes use of the XShm extension, and it seems like a good idea to see if Gecko couldn't do the same."
To read all comments associated with this story, please click here.
Member since:2005-07-06
This is a key point!
The "idiocy" comment in the original posting was way off-base. The XImage system actually makes a ton of sense. In most apps, you're drawing the same images over and over again (sprites, chrome). Its not a big deal to transfer them to the X server the first time they're drawn. In a web-browser context, you're drawing different images all the time, but what do you think is the bottleneck, copying the image to the X server, or downloading them from the internet?
Where XShm helps is when you dynamically generate images for each frame, and as such are constantly uploading new images to the Xserver to draw. However, even in that case, it is unlikely to provide a huge speedup, since the overall time is probably dominated by creating the image, not copying it to the X server.
Member since:2005-07-08
There's an additional big problem with sockets: Once you send the image to the server, the client can't "share" it, because it's living in the server's address space. So you have a copy of the image on the server AND exactly the same copy of the image on the client. The image is effectively using 2x its size in the memory.
The "right fix" for this stupid waste of resources is to free() the image on the client. With shared memory, you can SHARE the image's memory between the client and the process.
That's how things should work on a sane local graphic setup, but X is far from being "sane". Yes, X.org IS efficient and comparable to other systems, but only because people have spent a lot of time workarounding the stupid things it does so that at the end in local systems it works like other sane systems.
That's the funny thing: X is supposed to be "network transparent", but then the server and the client need to DETECT if they're in "local mode", or if such extension is enabled or not, and make SPECIAL MODIFICATIONS to the code paths so that it works right. There's no "transparency" anymore, as applications (toolkits) need to be aware of such low-level graphic details and code different paths according to the results. It has been needed to create many X extensions, it has been needed to MODIFY applications to use those extensions...oh my god, it's just not fun even to think about it. And to think that backwards compatibility is all that was stopping people from doing it right...
Edited 2008-06-29 09:20 UTC
Member since:2005-11-20
Well, we are speaking about Cairo here right?
Cairo is basically a software renderer. That implies that in fact you do all your rendering to the memory, then transfer the resulting image to X11.
That in fact implies that you rarely are able to "reuse" stored images. Each screen update means a new image and new transfer.
IME, the difference in image transfer is about 2x. OTOH, the rendering itself can perhaps take quite a bit of time too, so in practice, maybe it really is not that critical.
BTW, you can try it:
x11perf -putimage500
x11perf -shmput500
Member since:2005-07-06
Fedora 9 with all updates, redeon driver, AMD 3870, Phenom 9750
[storm@fast ~]$ x11perf -putimage500
x11perf - X11 performance program, version 1.5
The X.Org Foundation server version 10499902 on :0.0
from fast
Sun Jun 29 14:11:16 2008
Sync time adjustment is 0.0334 msecs.
2800 reps @ 2.0214 msec ( 495.0/sec): PutImage 500x500 square
2800 reps @ 1.9846 msec ( 504.0/sec): PutImage 500x500 square
2800 reps @ 1.9471 msec ( 514.0/sec): PutImage 500x500 square
2800 reps @ 1.9314 msec ( 518.0/sec): PutImage 500x500 square
2800 reps @ 1.9462 msec ( 514.0/sec): PutImage 500x500 square
14000 trep @ 1.9661 msec ( 509.0/sec): PutImage 500x500 square
[storm@fast ~]$ x11perf -shmput500
x11perf - X11 performance program, version 1.5
The X.Org Foundation server version 10499902 on :0.0
from fast
Sun Jun 29 14:12:17 2008
Sync time adjustment is 0.0305 msecs.
16000 reps @ 0.3851 msec ( 2600.0/sec): ShmPutImage 500x500 square
16000 reps @ 0.3684 msec ( 2710.0/sec): ShmPutImage 500x500 square
16000 reps @ 0.3661 msec ( 2730.0/sec): ShmPutImage 500x500 square
16000 reps @ 0.3684 msec ( 2710.0/sec): ShmPutImage 500x500 square
16000 reps @ 0.3680 msec ( 2720.0/sec): ShmPutImage 500x500 square
80000 trep @ 0.3712 msec ( 2690.0/sec): ShmPutImage 500x500 square
~5 times faster, not bad.
"So in summary... Google has pulled the plug on support on a protocol they've helped popularize, after years of promising interoperability, for reasons that are dubious at best, and in a way that leaves people who don't jump to the new Hangouts app unable to talk to their contacts without any feedback that their IMs aren't getting through... And they've done that with no warning to anyone. I imagine there's a bunch of people out there wondering where some of their buddies have gone, or why their messages aren't getting responses, because this isn't documented anywhere." Google really messed this up. Such a dick move.
The Tizen Greek Community has some screenshots of a very recent build of Tizen running on a Samsung GT-i8800. It looks wholly unremarkable.Joint statement to The Next Web from Microsoft and Google: "Microsoft and YouTube are working together to update the new YouTube for Windows Phone app to enable compliance with YouTube's API terms of service, including enabling ads, in the coming weeks. Microsoft will replace the existing YouTube app in Windows Phone Store with the previous version during this time." Good to know these children stopped acting like little pricks. Can we have full Google support in Windows 8 now, please?
Yahoo is acquiring Tumblr, the microblogging and social networking website, for $1.1 billion USD. Tumblr offers little revenue but lots of eyeballs if Yahoo can monetarize them. Now Yahoo is bidding for Hulu, the streaming video service. After years of ineffective responses while Google, Facebook, and others took large chunks of the online advertising market, Yahoo is fighting back. Can Yahoo reignite the momentum it had at the turn of the century? What do you think?
"Sources have described iOS 7 as 'black, white, and flat all over'. This refers to the dropping of heavy textures and the addition of several new black and white user interface elements." I couldn't be happier."Ilja van Sprundel, a security researcher with IOActive, has discovered a large number of issues in the way various X client libraries handle the responses they receive from servers, and has worked with X.Org's security team to analyze, confirm, and fix these issues."
"Google is facing a new antitrust probe by the U.S. Federal Trade Commission into whether the company is using its leadership in the online display-advertising market to illegally curb competition, people familiar with the matter said." Sucks to be Google today, apparently."In the midst of the major press blitz surrounding its annual I/O Conference, Google dropped some unfortunate news about its instant messaging plans. In several places around the web, the company is replacing the existing 'Talk' platform with a new one called 'Hangouts' that sharply diminishes support for the open messaging protocol known as XMPP (or sometimes informally Jabber), and also removes the option to disable the archiving of all chat communications. These changes represent a switch from open protocols to proprietary ones, and a clear step backward for many users." That's why I always say: only suckers trust companies."The wave of departures is a sign of internal struggle, but amidst all the bad news, there is a glimmer of hope. According to an anonymous HTC executive cited by WSJ, the crucial HTC One is selling 'pretty good so far'. The executive revealed that HTC sold about five million One units since launch, a performance that is deemed encouraging. However, sales have been limited by the persisting supply issues that still plague the production of the HTC One." Finally some good news for HTC. Five million units amidst supply constraints is very impressive.
"Sony gave the PS4 50% more raw shader performance, plain and simple (768 SPs @ 800MHz vs. 1152 SPs & 800MHz). Unlike last generation, you don't need to be some sort of Jedi to extract the PS4's potential here. The Xbox One and PS4 architectures are quite similar, Sony just has more hardware under the hood. Weâll have to wait and see how this hardware delta gets exposed in games over time, but the gap is definitely there. The funny thing about game consoles is that itâs usually the lowest common denominator that determines the bulk of the experience across all platforms. On the plus side, the Xbox One should enjoy better power/thermal characteristics compared to the PlayStation 4. Even compared to the Xbox 360 we should see improvement in many use cases thanks to modern power management techniques." AnandTech does its usual in-depth thing.
Member since:
2005-07-07
I think the article is exaggerating the problem.
True, transferring an image from the application to the X server takes quite some time and can be sped up using the shared memory extension.
However, an image does not have to be transferred every time it needs to be drawn.
As long as the application does not explicitly free the resources associated with the X server side image, it can be drawn or bitblitted with basically no delay.