[Spice-devel] hardcoded NUM_DRAWABLES too small

[Dietmar Maurer]

> 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.