> > 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. why is that better? I just want to disable local rendering. > > > 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. The number of character cells inside a terminal window is about 80x25 ==> 2000, so it is likely that a value of 1000 is not enough. ==> bigger is better for this particular problem > > 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? no - the application itself knows how to redraw. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel