> I think the hardcoded limit was intended for limiting the occupancy of the dev > ram with drawables that are referenced by the display channel. > If the limit is reasonable it should help with keeping allocations in the driver > fluent, and avoiding IO_OOM. > An alternative approach is to monitor the actual size that is currently occupied > by drawables that are referenced by the display channel, and to limit *this* size, > instead of the number of drawables. In fact, I've been lately working on such > approach + improving the timing of releasing resources. My code doesn't > remove the hardcoded NUM_DRAWABLES limit, but I think that after I post it, it > will be safer to remove this limit. interesting. > However, it is not that straight-forward to estimate the occupancy of the > devram on the server side, since, for example, we don't know the size of the > drawables that are pending in the cmd-ring. Also, the Windows driver has its own > cache, and different drawables may share the same memory (while I don't think > the Linux driver does the same). I see. > About the rendering on the server side, as Marc-André noted, at some point, > whether it is when the client connects, or when the memory limit is reached, the > drawables need to be rendered. The number of drawables that will be rendered > depends on their layout and if they cover one another, so that hidden drawables > can be dropped. I guess I have a very special case with 'spiceterm' - the application itself is able to re-generate the content. So I do not need that whole server side drawing code. I will try to disable it if I find some spare time. That would reduce memory and cpu usage for spiceterm. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel