DRC via TurboVNC-Users <[email protected]> writes:
> 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. Thanks! I will try to activate the ALR feature, and then discuss with emacs-devs to see what can be done there. > > 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 -- Joakim Verona [email protected] +46705459454 ------------------------------------------------------------------------------ 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
