On 10/19/12 20:04, Stefano Stabellini wrote: > On Wed, 17 Oct 2012, Gerd Hoffmann wrote: >> The vnc code uses *three* DisplaySurfaces: >> >> First is the surface of the actual QemuConsole, usually the guest >> screen, but could also be a text console (monitor/serial reachable via >> Ctrl-Alt-<nr> keys). This is left as-is. >> >> Second is the current server's view of the screen content. The vnc code >> uses this to figure which parts of the guest screen did _really_ change >> to reduce the amount of updates sent to the vnc clients. It is also >> used as data source when sending out the updates to the clients. This >> surface gets replaced by a pixman image. The format changes too, >> instead of using the guest screen format we'll use fixed 32bit rgb >> framebuffer and convert the pixels on the fly when comparing and >> updating the server framebuffer. > > Is this really a good idea? > It is very common for a vnc client to ask for 16 or 8 bpp on slow > connections.
The 16bpp modes (guest video modes) are slowly dying, so I think it is best to operate at 32bpp internally. First because we don't need to convert when reading the guest framebuffer. Second the format is easy to deal with. When sending out the data to the client we might have to convert, but that isn't new. cheers, Gerd
