----- Original Message ----- > > > I just detected that my simple spiceterm generates more than > > > > > > 1000 drawables, so alloc_drawable() always fail. > > > > > > > > > > > > The effect is that I always draw twice (on server and at client)! > > > > This is an area I am newbie ;) > > > > Isn't the server always drawing anyway at some point? > > No. There is no need to draw anything at the server side (for spiceterm). Ok, that would be interesting. I wonder if you are not better off implementing a new display channel for your use case, if you just need to send off your own rendering commands without any change. > > Isnt't the 1000 drawables limit just slowing down the caller (guest/vm > > side), to > > leave time for clients to process all drawables in the pipes. > > no, it leads to additional draw commands on the server side. So this is a > waste > of computing power. > > > What alternative do you propose? > > NUM_DRAWABLES=3000 Explain 3000? What if tomorrow you need a bigger terminal? We will need to change it again. > but I guess that can have a negative performance impact elsewhere? Mostly on memory consumption, but also probably on some other area, like latency or cpu usage. > > > I guess one would see the same effect when running a xterm inside a > > > VM, because > > > > > > a terminal has a size of 80x25 characters, which gives 2000 different > > > regions. > > > > > > > > > > > > What is the suggested way to avoid such things? > > > > I'll let someone else reply suggestion, as I don't know myself. > > > > > Also, I don’t think I need the rendered content on the server side for > > > spiceterm (why?). > > > > > So is it possible to disable server side rendering at all? > > > > If you don't have client connected or for reconnection, you still want > > complete > > rendering ready, no? > > No, I do not really need that. spiceterm only allows a single connection. Ok, but even for the first connection, you want to be shown with the current content, don't you? _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel