Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
For better performance...
For better performance...
Hello,
Why don't we talk a little about existing bottlenecks/ possible tune-up idea?
I have just done with a viewer-side tuning as an example. Take a look
Whenever using the Tight encoding, CPU usage was sky high and was occasionaly causing choppy slow updates.
This replacement for the SETPIXELS_NOCONV macro in ClientConnection.h will perform DIB conversion + BitBlt instead of hitting every dots by SetPixelV.
That made my viewer with Tight encoding use less CPU and no longer stick still while frequent updates are made. Possiblly considerable to be faster too.
[syntax="c"]#define SETPIXELS_NOCONV(buffer, x, y, w, h) \
{ \
/*Convert RGB <-> BGR*/ \
unsigned char* rgbtable = buffer; \
unsigned char rgbtemp; \
for(int i = 0; i < w * h; i++) \
{ \
rgbtemp = rgbtable[i * 4]; \
rgbtable[i * 4] = rgbtable[i * 4 + 2]; \
rgbtable[i * 4 + 2] = rgbtemp; \
} \
/*BitBlit Buffer Data*/ \
LPBITMAPINFO lpBmpInfo = (LPBITMAPINFO)HeapAlloc(GetProcessHeap(), \
HEAP_ZERO_MEMORY, sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD)); \
lpBmpInfo->bmiHeader.biSize=sizeof(BITMAPINFOHEADER); \
lpBmpInfo->bmiHeader.biWidth=w; \
lpBmpInfo->bmiHeader.biHeight=-h; \
lpBmpInfo->bmiHeader.biPlanes=1; \
lpBmpInfo->bmiHeader.biBitCount=32; \
lpBmpInfo->bmiHeader.biCompression=BI_RGB; \
HDC hMemDC = CreateCompatibleDC(m_hBitmapDC); \
HBITMAP hBitmap = \
CreateDIBitmap(m_hBitmapDC, &lpBmpInfo->bmiHeader, CBM_INIT, \
(void*)buffer, lpBmpInfo, DIB_RGB_COLORS); \
SelectObject(hMemDC, hBitmap); \
HeapFree(GetProcessHeap(),0,lpBmpInfo); \
DeleteObject(hBitmap); \
BitBlt(m_hBitmapDC, x, y, w, h, hMemDC, 0, 0, SRCCOPY); \
DeleteDC(hMemDC); \
}[/syntax]
well, i want someone to review it anyway since i know my crappy C skill is totally unreliable
(if you don't have a compiler environment, you could try my latest custom binary(#14) as shown below in the signature.)
any more speed-up idea?
Why don't we talk a little about existing bottlenecks/ possible tune-up idea?
I have just done with a viewer-side tuning as an example. Take a look
Whenever using the Tight encoding, CPU usage was sky high and was occasionaly causing choppy slow updates.
This replacement for the SETPIXELS_NOCONV macro in ClientConnection.h will perform DIB conversion + BitBlt instead of hitting every dots by SetPixelV.
That made my viewer with Tight encoding use less CPU and no longer stick still while frequent updates are made. Possiblly considerable to be faster too.
[syntax="c"]#define SETPIXELS_NOCONV(buffer, x, y, w, h) \
{ \
/*Convert RGB <-> BGR*/ \
unsigned char* rgbtable = buffer; \
unsigned char rgbtemp; \
for(int i = 0; i < w * h; i++) \
{ \
rgbtemp = rgbtable[i * 4]; \
rgbtable[i * 4] = rgbtable[i * 4 + 2]; \
rgbtable[i * 4 + 2] = rgbtemp; \
} \
/*BitBlit Buffer Data*/ \
LPBITMAPINFO lpBmpInfo = (LPBITMAPINFO)HeapAlloc(GetProcessHeap(), \
HEAP_ZERO_MEMORY, sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD)); \
lpBmpInfo->bmiHeader.biSize=sizeof(BITMAPINFOHEADER); \
lpBmpInfo->bmiHeader.biWidth=w; \
lpBmpInfo->bmiHeader.biHeight=-h; \
lpBmpInfo->bmiHeader.biPlanes=1; \
lpBmpInfo->bmiHeader.biBitCount=32; \
lpBmpInfo->bmiHeader.biCompression=BI_RGB; \
HDC hMemDC = CreateCompatibleDC(m_hBitmapDC); \
HBITMAP hBitmap = \
CreateDIBitmap(m_hBitmapDC, &lpBmpInfo->bmiHeader, CBM_INIT, \
(void*)buffer, lpBmpInfo, DIB_RGB_COLORS); \
SelectObject(hMemDC, hBitmap); \
HeapFree(GetProcessHeap(),0,lpBmpInfo); \
DeleteObject(hBitmap); \
BitBlt(m_hBitmapDC, x, y, w, h, hMemDC, 0, 0, SRCCOPY); \
DeleteDC(hMemDC); \
}[/syntax]
well, i want someone to review it anyway since i know my crappy C skill is totally unreliable
(if you don't have a compiler environment, you could try my latest custom binary(#14) as shown below in the signature.)
any more speed-up idea?
Last edited by lizard on 2005-06-15 22:42, edited 2 times in total.
Lizard
lizard,
UltraVNC-custom14 LAN -- LAN testing
1st test,
viewer web browser ie6 xp sp2 home fr
web applet java viewer work now well as expected
2nd test,
winvnc RC20.7 lizard build
if option Misc Share the server unchecked, vncviewer RC18 lizard build close after fews seconds
3 test
quick option, auto, work as well but flashing mice cursor or blinkind bar to much in my opinion!!
Your winvnc based RC20.7 + viewer based RC18 not work with dsmplugin 118 need a UltraVNC viewer RC19.5 or higher and File Transfer not work too (as you tell me and you know already )
because there no new feature added until v1,
your speed hack implementing,I think is a great work, personalized UltraVNC-lizard 1.00 final release with all features of viewer and winvnc classic that would be very appreciate
Nice your picture,
UlraVNC, the max speed vnc
UltraVNC-custom14 LAN -- LAN testing
1st test,
viewer web browser ie6 xp sp2 home fr
web applet java viewer work now well as expected
2nd test,
winvnc RC20.7 lizard build
if option Misc Share the server unchecked, vncviewer RC18 lizard build close after fews seconds
3 test
quick option, auto, work as well but flashing mice cursor or blinkind bar to much in my opinion!!
Your winvnc based RC20.7 + viewer based RC18 not work with dsmplugin 118 need a UltraVNC viewer RC19.5 or higher and File Transfer not work too (as you tell me and you know already )
because there no new feature added until v1,
your speed hack implementing,I think is a great work, personalized UltraVNC-lizard 1.00 final release with all features of viewer and winvnc classic that would be very appreciate
Nice your picture,
UlraVNC, the max speed vnc
Last edited by redge on 2005-06-16 01:56, edited 1 time in total.
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
ok, verified. thank you for reporting :>redge wrote:1st test,
viewer web browser ie6 xp sp2 home fr
web applet java viewer work now well as expected
probably something is wrong in TurboFrameThread's implementation.redge wrote:2nd test,
winvnc RC20.7 lizard build
if option Misc Share the server unchecked, vncviewer RC18 lizard build close after fews seconds
let me check it.
hmm... i think i'm gonna upgrade viewer's codebase in a couple of days and i believe those ugly *bad* will be gone.redge wrote:3 test
quick option, auto, work as well but flashing mice cursor or blinkind bar to much in my opinion!!
Your winvnc based RC20.7 + viewer based RC18 not work with dsmplugin 118 need a UltraVNC viewer RC19.5 or higher and File Transfer not work too (as you tell me and you know already )
thanks redge, for all the reports and contribution.
[mod=494,1127739782]removed bad word[/mod]
Last edited by lizard on 2005-09-26 13:03, edited 1 time in total.
Lizard
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
FAST looked at the code, possible ways to even make it faster.
SETPIXELS_NOCONV is called a lot of times, general it is not a good idea
the use mem allocation deallocation if it is called a lot.
-------------
LPBITMAPINFO lpBmpInfo = (LPBITMAPINFO)HeapAlloc(GetProcessHeap(),
HEAP_ZERO_MEMORY, sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD));
.....
HeapFree(GetProcessHeap(),0,lpBmpInfo);
------------
You better do the allocation at class level (only once and reuse)
----------
HDC hMemDC = CreateCompatibleDC(m_hBitmapDC);
......
DeleteDC(hMemDC);
----------
Possible this can also be done at class level
------
Take a look at the ultraencoder. This use an optimzed way for writing
to the viewer screen. Create dib, reuse and use memcpy to write to the dib. (same method as server use to capture screen data, but invers)
Only implemented for the UltraEncoder, never found time to implement it for the other....
SETPIXELS_NOCONV is called a lot of times, general it is not a good idea
the use mem allocation deallocation if it is called a lot.
-------------
LPBITMAPINFO lpBmpInfo = (LPBITMAPINFO)HeapAlloc(GetProcessHeap(),
HEAP_ZERO_MEMORY, sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD));
.....
HeapFree(GetProcessHeap(),0,lpBmpInfo);
------------
You better do the allocation at class level (only once and reuse)
----------
HDC hMemDC = CreateCompatibleDC(m_hBitmapDC);
......
DeleteDC(hMemDC);
----------
Possible this can also be done at class level
------
Take a look at the ultraencoder. This use an optimzed way for writing
to the viewer screen. Create dib, reuse and use memcpy to write to the dib. (same method as server use to capture screen data, but invers)
Only implemented for the UltraEncoder, never found time to implement it for the other....
very good idea. i kind of thought that too.Rudi De Vos wrote:You better do the allocation at class level (only once and reuse)
----------
HDC hMemDC = CreateCompatibleDC(m_hBitmapDC);
......
DeleteDC(hMemDC);
----------
Possible this can also be done at class level
let me fix it fast
-----ADDED------------------------------------------------------------
updated. about 2% CPU reduction seen out of avg35+-10% range on
AthlonXP-M 1700+, ProSagaveDDR 32MB, WindowsXP SP2, XGA 16bit.
try latest custom build (#15)
*this modification seems stable*
Last edited by lizard on 2005-06-16 19:52, edited 1 time in total.
Lizard
Hello,
"Tight encoding" is one of the most efficient VNC encoding around, but there's been bottlenecks that keeps CPU utilization real high especially on the viewer side.
The previous unit of discussion we made was about using BitBlt instead of SetPixelV for each dot on screen, and now this one is to solve the other side of bottleneck clearly seen. The JPEG performance.
Good news here. I've just done with another tuning, granting Intel JPEG Library compatibility to UltraVNC.
When IJG's libjpeg library (which is currently used with UltraVNC) does not perform the SIMD computations at all, this IJL adaptation seems to have reduced about 20-40% of CPU load on MMX/SSE-enabled systems, compared to libjpeg.
Anyone interested could download and try my custom binaries. The source code will be available in one or a couple of days.
"Tight encoding" is one of the most efficient VNC encoding around, but there's been bottlenecks that keeps CPU utilization real high especially on the viewer side.
The previous unit of discussion we made was about using BitBlt instead of SetPixelV for each dot on screen, and now this one is to solve the other side of bottleneck clearly seen. The JPEG performance.
Good news here. I've just done with another tuning, granting Intel JPEG Library compatibility to UltraVNC.
When IJG's libjpeg library (which is currently used with UltraVNC) does not perform the SIMD computations at all, this IJL adaptation seems to have reduced about 20-40% of CPU load on MMX/SSE-enabled systems, compared to libjpeg.
Anyone interested could download and try my custom binaries. The source code will be available in one or a couple of days.
Lizard
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Take care when you distribute IJL.
The original IJL license was free....but with one restriction, you need to
distribute the latest IJL librarary with your product.
The problem is that the latest IJL library is only available as part "performance library". This software is not free, and the downloadable (Try)version does not allow redistribution of dll
and samples.
As alternatives you can use the mmx accelerated IJG ( mpeg tools project sourceforge) or make use of RTJPEG (real time jpeg) library. The latest is real fast, but compression is a little less.
For Beta2, i wanted to do some lzo+rtjpeg test...have to fly.
Lizard, perhaps you can help with Beta2 ?
The original IJL license was free....but with one restriction, you need to
distribute the latest IJL librarary with your product.
The problem is that the latest IJL library is only available as part "performance library". This software is not free, and the downloadable (Try)version does not allow redistribution of dll
and samples.
As alternatives you can use the mmx accelerated IJG ( mpeg tools project sourceforge) or make use of RTJPEG (real time jpeg) library. The latest is real fast, but compression is a little less.
For Beta2, i wanted to do some lzo+rtjpeg test...have to fly.
Lizard, perhaps you can help with Beta2 ?
lizard and Rudi
ZRLE can be optimized too for slow connection (8000 km US to Europe example)
like your optimisation of Tight speed hack ?
(as quick option=modem (default)
ZRLE can be optimized too for slow connection (8000 km US to Europe example)
like your optimisation of Tight speed hack ?
(as quick option=modem (default)
so beautiful futur !For Beta2, i wanted to do some lzo+rtjpeg test...have to fly.
Lizard, perhaps you can help with Beta2 ?
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
Hello,
Even for slowest modem use, as long as Full-Color transmission is desired, I'd still prefer tuned-up Tight instead of ZRLE, just in the matter of the *speed*.
I believe that now in more than a few patterns of use UltraVNC has come comparablly comfortable to the Terminal Service.netwolf wrote:Using IJL sounds like a very good idea, and many sytems will benefit of this improvement!
That was a problem and why this version doesn't include the dll. But people could find one from the net easilyRudi De Vos wrote:The problem is that the latest IJL library is only available as part "performance library". This software is not free, and the downloadable (Try)version does not allow redistribution of dll
and samples.
My pleasure, rudi! Anytime if my poor skill may contribute.Rudi De Vos wrote:For Beta2, i wanted to do some lzo+rtjpeg test...have to fly.
Lizard, perhaps you can help with Beta2 ?
Only Tight encoding has ability of lossy compression method and I think it is nessecery for Full-Color optimization. Besides I think ZRLE has been already optimized almost maximally and that means very less space for optimization is rest.redge wrote:ZRLE can be optimized too for slow connection (8000 km US to Europe example)
like your optimisation of Tight speed hack ?
Even for slowest modem use, as long as Full-Color transmission is desired, I'd still prefer tuned-up Tight instead of ZRLE, just in the matter of the *speed*.
Lizard
the latest binaries and source code of custom build is out.
Pre-Compiled Binary (504KB) | Source (1423KB)
Binary zip includes server/client EXEs.
The server is based on UltraVNC 1.0 (24 Jun, 2005) Http (Single-Port) Build.
The client is based on UltraVNC 1.0 (24 Jun, 2005) Release build.
Each EXE was built for 686 using VC.NET 2003, and compressed using ASPack.
Following are the difference from the Original UltraVNC 1.0.
[mod=2,1119983261]Just applied list-tag for better readability[/mod]
Pre-Compiled Binary (504KB) | Source (1423KB)
Binary zip includes server/client EXEs.
The server is based on UltraVNC 1.0 (24 Jun, 2005) Http (Single-Port) Build.
The client is based on UltraVNC 1.0 (24 Jun, 2005) Release build.
Each EXE was built for 686 using VC.NET 2003, and compressed using ASPack.
Following are the difference from the Original UltraVNC 1.0.
- Support of Non-US keyboard IME layouts patch, as known as Japanese Kanji key patch, by UnderDone was applied.
- Smooth Animation patch (has been called TurboFrame) applied. Especially on connections with heavy-delays (say more than 100ms RTT,) the responsiveness would drastically improve.
- Stall Avoidance patch applied. Active mouse movement has been causing packet congestions, animation freezes and delays but not anymore.
- The Tight encoding was tuned up in numbers of methods, including a little adjustment of JPEG quality level. No gigantic CPU utilization any more.
- The Cache encoding works a bit more efficient.
- Cosmetic tweak-outs about the appearance, logo and icons.
- Mouse pointer used to unfocus VNC window and disappear upon shift to full-screen mode, but not any longer.
- When VNC is in the full-screen mode and another application window activates, VNC automatically minimizes itself.
- The viewer supports Intel JPEG Library 1.5 additional to the default IJG decoder. Just put ijl15.dll in your directory to activate its amazing MMX/SSE acceleration for full-color Tight encoding.
[mod=2,1119983261]Just applied list-tag for better readability[/mod]
Last edited by lizard on 2005-06-30 10:42, edited 1 time in total.
a comic-style explanation of the solution for another bottleneck
"driver buffer flows to force immediate update when scrolling" problem.
D is the "Driver buddy" and V is the "VNC dude."
imagine something like this
| A | B | C | D | E | F | G | H | ....
| 0 | 1 | 2 | 2 | 0 | 3 | 0 | 0 | ....
V is at the job in which he has to hear from D about updates of this table,
and tell that to the user. yes, like exactly what a VNC server has to do!
yet another lazy day...
D: I got an update! from F to H become 1,2,3.
V tells the user "F=1,2,3"
V: okay. what's next?
D: I got an update! from C to D become 4,5.
V tells the user "C=4,5"
V: okay. what's next?
:
:
(but now the user starts to scroll around and D is rushed with too many fast updates!
since VNC dude doesn't process things so fast as the Driver buddy, he's starting to annoy D.)
D: I got an update! from D to F become 2,3,4. hey it's getting really hard to remember...
V: sorry, i'm busy right now.
D: I got an update! from E to G become 1,2,3. I think I'm forgetting what was before...
V: hang on! I'm still processing the one in 1999 times ago!
D: I got an update! from B to C become 4,5.
(buffer reaches 2000)
D: Well, see I forgot the sequence! i'm only sure that B to G are 4,5,2,1,2,3!
V: hey calm down man!
how it used to be:
V: okay okay, I'm gonna do it! B to G 4,5....
(frightened to D's anger, V quits everything he was doing)
V tells the user "B=4,5,2,1,2,3"
user: d**n it! you spend my precious time by telling me such a huge worthless info!
how it should be:
V just memorizes B to G has to be updated later, because this data isn't important!
V: I'm done! come on, tell me the next!
D: alright, I got an update! from C to D become 4,5.
V tells the user "C=4,5"
V: okay. what's next?
:
:
(when D stops to tell updates)
V: hey, BTW a while ago when we're working busy you said B to G had been updated, right?
V: actually I didn't tell it to the user. can you tell me what are in the range now?
D: oh man! you didn't process it? well B to G are 4,5,2,6,7,8 now.
V: thx.
V now tells to the user the culminative update "B=4,5,2,6,7,8"
user: hm, this info was huge but was so important, you've got a good sence of timing!
here a few things to be careful about are:
maybe I better bring some pictures to let you understand easier...
"driver buffer flows to force immediate update when scrolling" problem.
D is the "Driver buddy" and V is the "VNC dude."
imagine something like this
| A | B | C | D | E | F | G | H | ....
| 0 | 1 | 2 | 2 | 0 | 3 | 0 | 0 | ....
V is at the job in which he has to hear from D about updates of this table,
and tell that to the user. yes, like exactly what a VNC server has to do!
yet another lazy day...
D: I got an update! from F to H become 1,2,3.
V tells the user "F=1,2,3"
V: okay. what's next?
D: I got an update! from C to D become 4,5.
V tells the user "C=4,5"
V: okay. what's next?
:
:
(but now the user starts to scroll around and D is rushed with too many fast updates!
since VNC dude doesn't process things so fast as the Driver buddy, he's starting to annoy D.)
D: I got an update! from D to F become 2,3,4. hey it's getting really hard to remember...
V: sorry, i'm busy right now.
D: I got an update! from E to G become 1,2,3. I think I'm forgetting what was before...
V: hang on! I'm still processing the one in 1999 times ago!
D: I got an update! from B to C become 4,5.
(buffer reaches 2000)
D: Well, see I forgot the sequence! i'm only sure that B to G are 4,5,2,1,2,3!
V: hey calm down man!
how it used to be:
V: okay okay, I'm gonna do it! B to G 4,5....
(frightened to D's anger, V quits everything he was doing)
V tells the user "B=4,5,2,1,2,3"
user: d**n it! you spend my precious time by telling me such a huge worthless info!
how it should be:
V just memorizes B to G has to be updated later, because this data isn't important!
V: I'm done! come on, tell me the next!
D: alright, I got an update! from C to D become 4,5.
V tells the user "C=4,5"
V: okay. what's next?
:
:
(when D stops to tell updates)
V: hey, BTW a while ago when we're working busy you said B to G had been updated, right?
V: actually I didn't tell it to the user. can you tell me what are in the range now?
D: oh man! you didn't process it? well B to G are 4,5,2,6,7,8 now.
V: thx.
V now tells to the user the culminative update "B=4,5,2,6,7,8"
user: hm, this info was huge but was so important, you've got a good sence of timing!
here a few things to be careful about are:
- when D forgets everything again before getting idle, V is going to memorize the range as well, and later on when asking culminative info, these ranges should be combined properly, or V has to send such a huge data twice!
for example, V knows "B to G" has been updated, and D forgets things and tells V that "A to F" become 1,2,3,4,5,6. now V knows "A to F" and "B to G" have been updated. so when getting idle and asking back to D about them, "A to G" should be asked, not "B to G and A to F"
I'd rather suggest him to combine them realtime and keep it as 2D map not array of range data. - V only knows "B to G" was updated. but what if "C to E" were moved to "F to H" after that? even though V tells it to the user, he isn't really sure what data was in "C to E!" that means he has to validate "F to H" some time. (or immediately?) so now he has to add "F to H" to his lazy update schedule.
simply, when a range of data including "not sure (=to be validated when idle)" area is moved to another, its destination also has to be marked "to be validated" or updated immediately. - when a "not sure" area is filled with data and become "sure,"
it should be deleted and excluded from V's update schedule.
maybe I better bring some pictures to let you understand easier...
Last edited by lizard on 2005-06-28 23:46, edited 1 time in total.
more simple and still efficiant way.
with it we can ignore those special rules.
1) only one frame "refresh when idle" data to keep.
2) when driver buffer reaches 2000, just memorize the rect position & size as "refresh when idle" and keep going with new updates.
3) when buffer reaches 2000 again before getting idle, compare the new rect to previous one. if the old rect is equivalent to the new one, or the old "includes" the new, still do nothing and keep going. if not, now refresh happens immediately.
simple and beautiful. scrolling will no longer stick your VNC.
---------added---------------------------
4) specially have to immediately refresh scheduled rect and the copyrect destination, upon copyrect out from "refresh when idle" area?
well, that is all. logically i can't think of a fault...
regards
---------added---------------------------
here's the abstract code of driver polling function replacement.
ScrollStallAvoidance.txt
with it we can ignore those special rules.
1) only one frame "refresh when idle" data to keep.
2) when driver buffer reaches 2000, just memorize the rect position & size as "refresh when idle" and keep going with new updates.
3) when buffer reaches 2000 again before getting idle, compare the new rect to previous one. if the old rect is equivalent to the new one, or the old "includes" the new, still do nothing and keep going. if not, now refresh happens immediately.
simple and beautiful. scrolling will no longer stick your VNC.
---------added---------------------------
4) specially have to immediately refresh scheduled rect and the copyrect destination, upon copyrect out from "refresh when idle" area?
well, that is all. logically i can't think of a fault...
regards
---------added---------------------------
here's the abstract code of driver polling function replacement.
ScrollStallAvoidance.txt
Last edited by lizard on 2005-06-29 01:03, edited 2 times in total.
at my user level knowledge (not developer understanding because i don't understand)lizard wrote:Only Tight encoding has ability of lossy compression method and I think it is nessecery for Full-Color optimization. Besides I think ZRLE has been already optimized almost maximally and that means very less space for optimization is rest.
Even for slowest modem use, as long as Full-Color transmission is desired, I'd still prefer tuned-up Tight instead of ZRLE, just in the matter of the *speed*.
I watch only result not how is made, sorry for your great effort for end-user, but very welcome for interest of coders, developers for better improving speed and realtime with good quality )
well,
Did you mean, we can obtain same result with your Tight(+ijl) speed hack as replacement for ZRLE full color on low bandwith (ISDN 64 -- 128k) or
I'm totallement miss understanding ?
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
Hello,
my opinion is definitely Tight for the full-color and ZRLE for any others.
first, on a slow connection PC's machine power is nothing, but only encoding's data compression efficiency matters here.
[why Tight is good for full color mode]
* Tight performs JPEG compression in the full-color mode
as limiting the subject to "full color," and as long as real *full-color data* is flowing, Tight in average is much faster than ZRLE because of its JPEG compression ability. in some cases ZRLE even takes 3 times longer than Tight would(!)
[why ZRLE is good for restricted color modes]
* RLE compression is extremely efficient in flat images
* Tight does NOT perform JPEG comp in restricted-color mode
but under restricted colors, on the other hand, ZRLE should be faster. as your screen contains more flat color distribution, RLE becomes more efficient. importantly to add, Tight doesn't perform JPEG compression in the pseudo-color mode.
since i personally don't really like any restricted-color mode, i prefer to always use Tight+JPEG in full-color mode so i don't have to care about what kind of image is going to be shown fast and what is slow or anything. never a need to switch encoding but it works generally fast enough for all purpose of use.
i hope it helps.
okay,redge wrote:Did you mean, we can obtain same result with your Tight(+ijl) speed hack as replacement for ZRLE full color on low bandwith (ISDN 64 -- 128k) or
I'm totallement miss understanding ?
my opinion is definitely Tight for the full-color and ZRLE for any others.
first, on a slow connection PC's machine power is nothing, but only encoding's data compression efficiency matters here.
[why Tight is good for full color mode]
* Tight performs JPEG compression in the full-color mode
as limiting the subject to "full color," and as long as real *full-color data* is flowing, Tight in average is much faster than ZRLE because of its JPEG compression ability. in some cases ZRLE even takes 3 times longer than Tight would(!)
[why ZRLE is good for restricted color modes]
* RLE compression is extremely efficient in flat images
* Tight does NOT perform JPEG comp in restricted-color mode
but under restricted colors, on the other hand, ZRLE should be faster. as your screen contains more flat color distribution, RLE becomes more efficient. importantly to add, Tight doesn't perform JPEG compression in the pseudo-color mode.
since i personally don't really like any restricted-color mode, i prefer to always use Tight+JPEG in full-color mode so i don't have to care about what kind of image is going to be shown fast and what is slow or anything. never a need to switch encoding but it works generally fast enough for all purpose of use.
i hope it helps.
Lizard
Sources / Diff
Lizard,
your mods are really cool, especially on lines with latency (which almost always happens with remote support over far distances)
I couldn't download the sources, they were not found on the server - did you change the link?
BTW: How many files did you change? Do you have a Diff list?
I would like to include the diffs in the TeamViewer project that we are using and which is also based on UltraVNC.
Tom
your mods are really cool, especially on lines with latency (which almost always happens with remote support over far distances)
I couldn't download the sources, they were not found on the server - did you change the link?
BTW: How many files did you change? Do you have a Diff list?
I would like to include the diffs in the TeamViewer project that we are using and which is also based on UltraVNC.
Tom
Re: Sources / Diff
Hello,
Thank you for your interest in the modification.
thanks
Thank you for your interest in the modification.
Sorry that I put wrong link. it is fixed now.Tom Waters wrote:I couldn't download the sources, they were not found on the server - did you change the link?
That archive is grab-n-go package which can be directly built after download. If diff list was prefered i could provide one.Tom Waters wrote:How many files did you change? Do you have a Diff list?
I wrote and tested the mod carefully, but since I wasn't familiar to C++ at all, there might still be unrevealed problems in my code. So, as well as any other "newly implemented" code, first I need someone to review and make sure it won't break anything, especially before merging into any other product.Tom Waters wrote:I would like to include the diffs in the TeamViewer project that we are using and which is also based on UltraVNC.
thanks
lizard
thank you for your good hints
well,
waiting your next sign updated about your new improvement speed and quality.
http://lizard.ddo.jp:81/ultravnc-100a-lizard.zip, done
http://lizard.ddo.jp:81/ultravnc-100b-lizard.zip ?
thank you for your good hints
well,
waiting your next sign updated about your new improvement speed and quality.
http://lizard.ddo.jp:81/ultravnc-100a-lizard.zip, done
http://lizard.ddo.jp:81/ultravnc-100b-lizard.zip ?
UltraVNC 1.0.9.6.1 (built 20110518)
OS Win: xp home + vista business + 7 home
only experienced user, not developer
OS Win: xp home + vista business + 7 home
only experienced user, not developer
How about a form of progressive encoding so that fast changes appear fast, but when the bandwidth is available everything still appears at high quality. I imagine it would work like this:
S sends a 'blurry' version of the update. (E.g. like fuzzy encoding)
S checks if major changes on screen:
-If major changes, send new 'blurry' update
-If no major changes, send '2nd half' of update containing differences from 'blurry' updates
S sends a 'blurry' version of the update. (E.g. like fuzzy encoding)
S checks if major changes on screen:
-If major changes, send new 'blurry' update
-If no major changes, send '2nd half' of update containing differences from 'blurry' updates
-
- Posts: 3
- Joined: 2005-06-06 10:02
my two cents about the pregressive encoding:
A 100% compatible way to implement. I think...
Only server needs to be modified, so an old viewer -and also tightvnc viewer- can benefit of this strategy.
Server behaviour -> tight encoder with JPEG enabled
- Sends changed rectangle with jpeg al worst quality (even worst than 0 setting); rectangle added to a stack of 'partially sent'.
- If more changes to send; ok, send.
- When no more changes; then send rectangle from 'partially sent' stack but with better quality (add 1 to setting of jpeg quality).
- If even with no changes, send again from stack with even better quality (add 1 more to jpeg quality)
- Repeat until reached user selectec quality (i.e. 6 jpeg quality) or rectangle changed.
when detected change in area with copy on stack, then discard data from stack or update data.
Do you understand?
Regards
Juan Belmonte
P.D.: Sorry for my bad english
A 100% compatible way to implement. I think...
Only server needs to be modified, so an old viewer -and also tightvnc viewer- can benefit of this strategy.
Server behaviour -> tight encoder with JPEG enabled
- Sends changed rectangle with jpeg al worst quality (even worst than 0 setting); rectangle added to a stack of 'partially sent'.
- If more changes to send; ok, send.
- When no more changes; then send rectangle from 'partially sent' stack but with better quality (add 1 to setting of jpeg quality).
- If even with no changes, send again from stack with even better quality (add 1 more to jpeg quality)
- Repeat until reached user selectec quality (i.e. 6 jpeg quality) or rectangle changed.
when detected change in area with copy on stack, then discard data from stack or update data.
Do you understand?
Regards
Juan Belmonte
P.D.: Sorry for my bad english
Lizard,
I downloaded your 1.00b mod and tried it, looks good, but:
In Danish, to type a backslash \ you need to use the combo
AltGr+< (press the < left of Z while holding down the AltGr right of Space)
which work fine with UltraVNC Release 1.00 but not with your mod.
I guess it could be a side-effect of the multi-locale thing.
I know Danish is a small language, but I really use \ a lot
Keep up the good work
Rasmus
I downloaded your 1.00b mod and tried it, looks good, but:
In Danish, to type a backslash \ you need to use the combo
AltGr+< (press the < left of Z while holding down the AltGr right of Space)
which work fine with UltraVNC Release 1.00 but not with your mod.
I guess it could be a side-effect of the multi-locale thing.
I know Danish is a small language, but I really use \ a lot
Keep up the good work
Rasmus
i think i found the scroll problem's essential.
the key point is where screen change informed from the mirror driver is processed and the copyrect source is scheduled to be refreshed. (vncdesktopthread.cpp:972)
@rmoller:
I'm sorry that I didn't check this forum recently.
let me check the problem. thank you for reporting.
the key point is where screen change informed from the mirror driver is processed and the copyrect source is scheduled to be refreshed. (vncdesktopthread.cpp:972)
- when in the next update cycle this scheduled region is scanned, actual region content may have been changed.
this must be directly causing refreshes while active scrolling. - generally copyrect "source" and "destination" share some of each other's area.
this also is nessecery to result in forced refreshes, but looks like it's helping recovery from scrolled area corruption (caused by 1) too.
@rmoller:
I'm sorry that I didn't check this forum recently.
let me check the problem. thank you for reporting.
Last edited by lizard on 2005-07-09 20:07, edited 1 time in total.
Lizard
as you can see, even when copyrect source and destination share their areas refresh on the conflicting region is forced anyway.
since VNC screen data check delays from driver GDI call and there's no help for possible screen corruption by that, this at least should be considered a speed improvement not a bug feeding...
the key point must be around vncdesktopthread.cpp:950-980
for the above modification i think we need to acquire "copyrect destination" info even though vncdesktopthread.cpp:948-950 says not.
as well as vertical, the horizontal and tilt motion (which frequently happens upon window/icon drag&drop operation) should also be considered.
Lizard
this archive includes D source code and precompiled .exe.
VNCEncodeUntitled-proto1.zip
first conceptual implementation of a part of new encoding. (area detection similar to Tight's)
once you run the executable, it separates the contents of your screen in a logic and shows the result.
the red area indicates the solid-color area.
the green area can be encoded into "1bit/pix palette color."
the blue area is where judged to be better compressed by JPEG.
*speed is not considered for this one*
any comments are welcome.
regards
VNCEncodeUntitled-proto1.zip
first conceptual implementation of a part of new encoding. (area detection similar to Tight's)
once you run the executable, it separates the contents of your screen in a logic and shows the result.
the red area indicates the solid-color area.
the green area can be encoded into "1bit/pix palette color."
the blue area is where judged to be better compressed by JPEG.
*speed is not considered for this one*
any comments are welcome.
regards
Last edited by lizard on 2005-07-27 09:13, edited 1 time in total.
Lizard
archive includes D source code and precompiled .exe.
VNCEncodeUntitled-proto2.zip
second conceptual implementation of area detection.
alround performance improvement (speed, accuracy, validity) were done.
a few detection bugs were fixed.
once you run the executable, it separates the contents of your screen in a logic and shows the result.
the green area can be encoded into "1bit/pix palette color" to reduce traffic.
the blue area is where judged to be better compressed in JPEG.
regards
VNCEncodeUntitled-proto2.zip
second conceptual implementation of area detection.
alround performance improvement (speed, accuracy, validity) were done.
a few detection bugs were fixed.
once you run the executable, it separates the contents of your screen in a logic and shows the result.
the green area can be encoded into "1bit/pix palette color" to reduce traffic.
the blue area is where judged to be better compressed in JPEG.
regards
Lizard
Thank you for your up to date custom build with the Japanese Kanji key patch! It is so nice to be able to use the Japanese keys on my keyboards. I tried several other client/servers, some of which made the IME invisible completely preventing me from typing in Japanese. I cant tell you enough how very glad I am to have your custom build. Thanks!!!
- Rudi De Vos
- Admin & Developer
- Posts: 6862
- Joined: 2004-04-23 10:21
- Contact:
Rudi
It would be nice that those that are working ok would become part of the main ultravnc. A faster response time would still be an advantage.
Alain
I can understand thatRudi De Vos wrote:Non of the opimizations are implemented in 1.0.1.
We where to afraid to add some new bug again and time was running
out for rel 1.00
But if lizard want, we can see if some of them can be imported, together with some reconnect patch.
It would be nice that those that are working ok would become part of the main ultravnc. A faster response time would still be an advantage.
Alain