On 11/30/07, Richard Boaz <riboaz@xxxxxxxxx> wrote: > Sorry, I can't think of a single application responsible for making its > own drawings by hand where option 2 is not crazy hard. (If anybody has an > example of this in real-world application, please post?) My 2p: Most applications let you zoom the display, or at least have a main window which is a viewport into a much larger document. There's no way you can keep a pixmap for the whole thing (imagine a word processor, or an image editor with the display zoomed in 10 times), so you will always have to have some mechanism for clipping your document view against a viewport. Once you have this, it's trivial to clip against each expose event rather than the viewport, and once you do that, you don't need a backing pixmap. No pixmap means less memory use (X server memory is still constrained, so this is a win), and the slight loss in speed is more than made up for (IMO) by the drop in latency due to not having to manage a large memory object. My app, for example, is an image processing package. The images are very expensive to generate, so I keep parts of them around (in a tile cache) on the client side. On an expose, I extract the set of rects for the damaged area from the image and paint them to the screen, then I loop over all the image annotations and for each one test for bounding-box-of-expose-intersects-bounding-box-of-annotation. If there is an intersection, I redraw that annotation. I will only ever have a few hundred annotations, so I can just loop over a list. If I had 900m objects (!!!!eeek) then yes, I'd need either a very fast culling algorithm (quad trees or some such I suppose) or a cache of pre-rendered views I could paste from. Even in this case I would still compose the window in expose: add rubber-band objects, annotations, axies, etc. But I think very few applications have to deal with datasets of this size. (though my image processing app can do multi-gigabyte images, so maybe that is of a similar scale, if you consider each pixel to be a separate object) John _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
