Comments on: Cairo, Xlib, and the Shared Memory Extension http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/ Game Development and Programming Tue, 06 Jan 2009 02:56:58 +0000 http://wordpress.org/?v=2.6 By: Eric Butler’s Weblog » Blog Archive » Adventures in X Programming http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-22 Eric Butler’s Weblog » Blog Archive » Adventures in X Programming Sat, 05 Jul 2008 21:33:35 +0000 http://www.ericbutler.net/blog/?p=6#comment-22 [...] Eric Butler’s Weblog something about programming and game making and stuff like that « Cairo, Xlib, and the Shared Memory Extension [...] [...] Eric Butler’s Weblog something about programming and game making and stuff like that « Cairo, Xlib, and the Shared Memory Extension [...]

]]> By: Dustin http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-20 Dustin Thu, 03 Jul 2008 07:28:58 +0000 http://www.ericbutler.net/blog/?p=6#comment-20 vsync: X will grow to INSANE memory usage if you have pixman 0.11.4, because it doesn't free redrawn regions or something to that effect. Upgrade pixman and everything may be fine. vsync: X will grow to INSANE memory usage if you have pixman 0.11.4, because it doesn’t free redrawn regions or something to that effect. Upgrade pixman and everything may be fine.

]]> By: William Lahti http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-19 William Lahti Tue, 01 Jul 2008 19:34:21 +0000 http://www.ericbutler.net/blog/?p=6#comment-19 Ahh I see you've already replied to that point. Well, sending the data one time is a HUGE difference from transferring per each change or even per each frame. In fact, XSHM looks extremely effective compared against images but how about you post a few benchmarks comparing xlib+xrender vs xshm and THEN we will see how impressive it is! Ahh I see you’ve already replied to that point. Well, sending the data one time is a HUGE difference from transferring per each change or even per each frame. In fact, XSHM looks extremely effective compared against images but how about you post a few benchmarks comparing xlib+xrender vs xshm and THEN we will see how impressive it is!

]]> By: William Lahti http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-18 William Lahti Tue, 01 Jul 2008 19:30:50 +0000 http://www.ericbutler.net/blog/?p=6#comment-18 Why do you not mention XRender... just using normal xlib pixmap surfaces to do this!? I mean, certainly XSHM surfaces would be very useful where you really must keep a few image surfaces around, but in most cases (especially for static graphics files) you can blit them from the image surface into your xlib pixmap and then destroy the original image surface. I have NO CLUE why exactly firefox isn't using such a method--- perhaps they need a cairo coach :-) ? Why do you not mention XRender… just using normal xlib pixmap surfaces to do this!? I mean, certainly XSHM surfaces would be very useful where you really must keep a few image surfaces around, but in most cases (especially for static graphics files) you can blit them from the image surface into your xlib pixmap and then destroy the original image surface. I have NO CLUE why exactly firefox isn’t using such a method— perhaps they need a cairo coach :-) ?

]]> By: Sean http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-16 Sean Sun, 29 Jun 2008 16:44:09 +0000 http://www.ericbutler.net/blog/?p=6#comment-16 Z_God: try changing your theme. GTK+ doesn't do anything particularly bad for remote connections (neither does it do things particularly well, either), but a bad theme can easily slaughter your performance, as it might cause an unnecessary number of image draws and other operations to be performed. markus: given that the Xorg guys wrote the Xshm extension for this very reason, I doubt they will hate it. They're not as stupid as this assholish blog post makes them out to be. The author might try to remember that X was originally designed in a day and age when image data was not anywhere close to the size it is today, and that without that network-centric design we wouldn't have the power and flexibility of networked X that we have and use today. It isn't "idiocy" to design X the way it is -- it is at worst an oversight of the application and toolkit authors who ignore the Xshm extension. vsync: try xrestop, which exists for that very purpose. keep in mind that Linux is going to report a lot of memory usage for X11 that has nothing to do with your actual usage of RAM, such as video memory usage. Also keep in mind how memory allocation works, and that a large variety of memory allocations will never be released to the OS until the application ends. malloc() grows the heap for smaller block requests, and unless _all_ blocks in the end of the heap are freed, the application cannot shrink the heap. Larger allocations (like some -- but not all -- image data) are often allocated using a different technique that makes it possible to immediately free the memory back to the OS when the application is done with the block. Z_God: try changing your theme. GTK+ doesn’t do anything particularly bad for remote connections (neither does it do things particularly well, either), but a bad theme can easily slaughter your performance, as it might cause an unnecessary number of image draws and other operations to be performed.

markus: given that the Xorg guys wrote the Xshm extension for this very reason, I doubt they will hate it. They’re not as stupid as this assholish blog post makes them out to be. The author might try to remember that X was originally designed in a day and age when image data was not anywhere close to the size it is today, and that without that network-centric design we wouldn’t have the power and flexibility of networked X that we have and use today. It isn’t “idiocy” to design X the way it is — it is at worst an oversight of the application and toolkit authors who ignore the Xshm extension.

vsync: try xrestop, which exists for that very purpose. keep in mind that Linux is going to report a lot of memory usage for X11 that has nothing to do with your actual usage of RAM, such as video memory usage. Also keep in mind how memory allocation works, and that a large variety of memory allocations will never be released to the OS until the application ends. malloc() grows the heap for smaller block requests, and unless _all_ blocks in the end of the heap are freed, the application cannot shrink the heap. Larger allocations (like some — but not all — image data) are often allocated using a different technique that makes it possible to immediately free the memory back to the OS when the application is done with the block.

]]> By: Bodo Linux grafični programi postali hitrejši? « lukov blog http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-15 Bodo Linux grafični programi postali hitrejši? « lukov blog Sun, 29 Jun 2008 15:09:42 +0000 http://www.ericbutler.net/blog/?p=6#comment-15 [...] popravek za knjižnico cairo, ki skrbi za vektorski izris grafike za Gtk+ programe kot za Firefox. Raziskava, ki jo je opravil in njeni rezultati pa so osupljivi, saj so s popravljeno cairo knjižnico, ki [...] [...] popravek za knjižnico cairo, ki skrbi za vektorski izris grafike za Gtk+ programe kot za Firefox. Raziskava, ki jo je opravil in njeni rezultati pa so osupljivi, saj so s popravljeno cairo knjižnico, ki [...]

]]> By: Bastiaan http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-14 Bastiaan Sun, 29 Jun 2008 08:45:12 +0000 http://www.ericbutler.net/blog/?p=6#comment-14 Did you ever talk to any of the Cairo people about this? If you had, you might have noticed that they have an experimental branch with XShm support. However, the verdict is still out whether or not this actually benefits performance in the long run /for internal usage in Cairo/. They have done a lot of benchmarking. You might wish to simply continue that if you wish to work on this. Did you ever talk to any of the Cairo people about this?

If you had, you might have noticed that they have an experimental branch with XShm support. However, the verdict is still out whether or not this actually benefits performance in the long run /for internal usage in Cairo/.

They have done a lot of benchmarking. You might wish to simply continue that if you wish to work on this.

]]> By: vsync http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-13 vsync Sun, 29 Jun 2008 01:01:28 +0000 http://www.ericbutler.net/blog/?p=6#comment-13 Neat stuff. Good work, look forward to even faster Firefox and the like! Unrelated question, but you might be a good person to ask. I notice on my machine here that after some days of X11 usage including heavy Firefox browsing etc, my Xorg process crawls up to 900MB or so memory usage. Could this be from pixmap caching? Is there any way to tell what's using the memory and purge it? It persists even after I close all apps, until I restart the X server itself. Neat stuff. Good work, look forward to even faster Firefox and the like!

Unrelated question, but you might be a good person to ask. I notice on my machine here that after some days of X11 usage including heavy Firefox browsing etc, my Xorg process crawls up to 900MB or so memory usage. Could this be from pixmap caching? Is there any way to tell what’s using the memory and purge it?

It persists even after I close all apps, until I restart the X server itself.

]]> By: markus http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-12 markus Sat, 28 Jun 2008 23:47:22 +0000 http://www.ericbutler.net/blog/?p=6#comment-12 This sounds like a great news but I am sure some Xorg guys will hate it ... :) This sounds like a great news but I am sure some Xorg guys will hate it … :)

]]> By: Tim http://www.ericbutler.net/blog/2008/06/cairo-xlib-and-the-shared-memory-extension/#comment-11 Tim Sat, 28 Jun 2008 23:29:03 +0000 http://www.ericbutler.net/blog/?p=6#comment-11 Web pages often involve many small images, so I am wondering if there will be a big improvement in general? It seems you could greatly improve the performance if you did not have to setup and tear down the shared memory segment each time. Could you use a custom pool allocator that reused the same shared mem ptr? Web pages often involve many small images, so I am wondering if there will be a big improvement in general? It seems you could greatly improve the performance if you did not have to setup and tear down the shared memory segment each time. Could you use a custom pool allocator that reused the same shared mem ptr?

]]>