Quote:
Originally Posted by elementarythree
Didn't think it was the mod, just included what exactly I used for completeness sake. Maybe in the future onyx does something about the CPU load and then me mentioning I used the original App could be confusing for people googling about it. I'm surprised and not surprised at the same time
|
I know. Also precising.
EDIT: I have not done any profiling (effort I did not need to spend), but the Monitor.apk from Onyx should be checked for heavy loops.
Quote:
Originally Posted by elementarythree
x11vnc is relatively clever about what screen regions got changed and what not, it uses the XDAMAGE extension in the xserver which is exactly for that
|
«Relatively», exactly: were things simple...
Quote:
Note that the DAMAGE extension does not speed up the actual reading of pixels from the video card framebuffer memory, by, say, mirroring them in main memory. So reading the fb is still painfully slow (e.g. 5MB/sec), and so even using X DAMAGE when large changes occur on the screen the bulk of the time is still spent retrieving them. Not ideal, but use of the ShadowFB XFree86/Xorg option speeds up the reading considerably (at the cost of h/w acceleration.)
Unfortunately the current Xorg DAMAGE extension implementation can at times be overly conservative and report very large rectangles as "damaged" even though only a small portion of the pixels have actually been modified. This behavior is often the fault of the window manager (e.g. it redraws the entire, unseen, frame window underneath the application window when it gains focus), or the application itself (e.g. does large, unnecessary repaints.)
To work around this deficiency, x11vnc currently only trusts small DAMAGE rectangles to contain real damage. The larger rectangles are only used as hints to focus the traditional scanline polling (i.e. if a scanline doesn't intersect a recent DAMAGE rectangle, the scan is skipped.) You can use the "-xd_area A" option to adjust the size of the trusted DAMAGE rectangles. The default is 20000 pixels (e.g. a 140x140 square, etc.) Use "-xd_area 0" to disable the cutoff and trust all DAMAGE rectangles.
|
Quote:
Originally Posted by elementarythree
tigervnc "vncserver script" (and it's also just a perl script, it uses xvnc) also uses all inherent xvnc advantages. (xvnc is basically an X server that only has a virtual screen that exists in memory) I sometimes play full-blown videogames via WINE and xvnc&VirtualGL on my desktop
|
So, you get a performance boost?
Quote:
Originally Posted by elementarythree
bVNC gets a bit more efficient in a low-latency connection if you enable it's hextile compression, as it's a very low compression level and doesn't weight down the CPU on both sides as much. I'm not sure if it does jpeg compression as it doesn't mention it anywhere but turning that off would probably help too
|
Yes bVNC does have compression levels and JPG quality levels. You do not need to turn it off (it would probably be a bad idea transmitting uniform blocks), just set it low and the CPU impact is minimal. You should have found in the thread also modifications of mine to Iordanov's bVNC, including full screen refresh and mode switch during application use. (Initially I had the bad idea of setting a high compression level, which on the very slow CPU of the MaxCarta was a nailed snail in agony, then I published a version with clever compression and quality parameters (compression: 1/10, quality 5/10).
I had bad results with hextile.
I discussed with Iordan about adding more options about it (of course, I doubt he will ever embed the Onyx SDK for tricks like "full screen refresh" and "EPD mode switch" though - hence the modifications and repackaging).
You can find the modified bVNC here:
https://www.mobileread.com/forums/sh...29#post3514529