Pity the spec is lacking some things, compared to the Moz implementation. Specifically, drawing text along paths, and creating a path from text. The former of which can be *very* useful.

In other words, we’d have three stages in the life of an image:

1) Image is not all decoded, needs to be drawn, not in shared memory, use XPutImage.
2) Image is not all decoded, in shared memory, use XShm
3) Image decoded, optimize.

Or would we never hit stage 2 in practice?

Another interesting question here is how often we in fact end up having to draw an image that is only partially decoded and whether we can reasonably reduce the number of times this happens (in other words, try hard to only draw images that have been optimized to pixmaps). Would that have similar performance benefits without the obvious pain of the XSync hit?

I should also note that the XSync hit will always be worse (a LOT worse) on a non-local X, so it’s something we should, imo, either avoid or make optional (e.g. disable the Shm thing based on a pref) if possible.

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.