I apologize for the delay. This message suffered from Acute Inbox Burial Syndrome. "Back in the day", X11 applications would draw using X11 primitive functions, such as XDrawText(). Such applications would thus update only small areas of their windows at a given time. These days, however, most applications have switched to using drawing methods based on the X RENDER extension (it is necessary to do this in order to support anti-aliased fonts), so even something as simple as Emacs may be updating the entire window image each time a single character changes. In fact, it's probable that they're updating the entire window image each time the cursor blinks.
In my testing (with a RHEL 6 server and Emacs 23.1.1), what seems to happen is that the characters are almost always sent as lossy JPEG if the compression level is 1 or 6. If the compression level is 2 or 7, the text is sent losslessly as I type, but when I press Enter to create a new line, the line I just typed is sent with lossy JPEG. With CL 1 or 6, TurboVNC will only send a subrectangle as JPEG if it has > 24 colors, and apparently most of the anti-aliased font characters exceed that number of colors (but not all-- typing characters without curves, such as "l" or "1" or "7", always seems to produce a lossless image.) I don't observe that the Emacs window is re-sent as lossy after a lossless refresh, unless I change the text in some way (for instance, by introducing another new line, which causes the previous lines to be re-rendered.) It sounds like what you're looking for is the Automatic Lossless Refresh feature in the server. That feature re-sends lossy regions as lossless after a specified period of inactivity. However, I observe that ALR (even with its most liberal setting-- TVNC_ALRALL=1) doesn't seem to work with Emacs, which is further evidence that Emacs may be constantly re-drawing its window image and thus foiling the ALR algorithm. On 7/11/17 1:06 PM, [email protected] wrote: > How are screen changes detected? > > I think it is easier to explain with an example. > > - start emacs, graphical mode, in a turbovnc session > > - set the image compression to low quality > > - depending on your emacs color theme you will see that the encoding is > in fact low quality, especially obvious with red colors against black > backgrounds. > > - now request a lossless screen refresh, using the f8 menu, or > ctrl-shift-alt-l > > - the display will be hiqh quality for a while but then quickly go back > to low quality > > > According to my uninformed intuition, the quality shouldnt go back to > low quality, because the screen havent changed at all, I'm just looking > at text. > > The reason I'm interested in this at all, is because it would be nice to > implement some kind of progressive encoding, where quality is low during > for instance scrolls, and then when the display is still, a higher > quality image is sent. > > Maybe turbovnc already works this way, and my locally compiled emacs > maybe signals display changes too often or something. Hence my original > question. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
