cbeerse at gmail
Jun 25, 2010, 3:06 AM
Post #4 of 4
On 18-6-2010 15:21, Seak, Teng-Fong wrote:
Re: VNC response depends on screen response
[In reply to]
> On Thu, Jun 17, 2010 at 10:20, Corne Beerse<cbeerse [at] gmail> wrote:
>> On 15-6-2010 17:59, Seak, Teng-Fong wrote:
>>> It seems that VNC response depends on screen response, ie VGA
>>> card's speed. I think VNC only sends screen updates to client only
>>> after corresponding pixels are changed on screen (ie in VGA memory).
>>> Am I correct?
>> This is only true for the native msWindows server side implementation:
>> There the vnc-server (the remote side) just grabs the contents of the
>> screen-memory and forwards that. Hence, the screen update of the session
>> can never be faster/better than the hardware. It's even worse: depending
>> on the way the screen-memory is grabbed, the screen update can be realy
> Is real VNC for Windows such "native ms windows server side
> implementation"? And is it possible to know in which way the
> screen-memory is grabbed?
See the vnc server properties, tab 'capture method':
- Poll for changes to the desktop: just frequently scans the video
memory for changes and sends that as updates to the viewers
- use vnc hooks to trace changes: vnc-server hooks into the display
driver and sends updates as the happen. This might slow down for systems
that do verry fast updates.
- I'm not sure, but I think the 'poll console windows for updates' is
for full screen applications.
- I donnot know what 'alpha blended windows' are so I donnot know what
this option does.
>> To make it even worse: the hardware accelerated video display stuff does
>> not use the memory for the screen, it inserts the picture 'on the fly'.
>> Hence where the real display shows the movie, the vnc-session shows a
>> black square.
> I'm not interested in movie related problem, so this doesn't
> concern me, correct?
It's not only movies, it includes every application that does direct
display updates. I'm not sure but I think even a lot of direct-x
applications are involved here.
>> There are however vnc-server installations that are linked more to the
>> display-driver and might do a better job on some side.
> Essentially the same question as above: I'm using real VNC for
> windows, so how could I know if the server installations are linked to
> the display driver or not?
For example, see the option 'Use VNC hooks to track changes' in the vnc
server capture methods properties. That is the kind of link I mean.
>>> I've got a PC whose VGA card is "ATI 3D RAGE IIC PCI". On the
>>> screen, the response is quite good. But when used in VNC, the
>>> response is horrible -- very slow.
>>> Is there any plan to improve this part? Eg using threads if
>>> that's not used already.
>> Try to find a vnc-server that is tailored to your display hardware.
Twiggle with the capture options.
On top of that, there are several splits from the origional vnc.
RealVNC, TrueVNC, TightVNC and UltraVNC are ones that come to mind.
>> On the other hand, using the current installation, twiggle a little with
>> the way the screen is updated/captured/refreshed.
> I'm already using "Use VNC hooks to track changes". Should I
> disable it? But that would mean I have to switch to "Poll for changes
> to the desktop". Isn't this a worse option?
It sound strange but disabling this setting can speed up things. I had
an application that did a complete window update more than once per
second. Switching back to the default polling gave me a workable solution.
VNC-List mailing list
VNC-List [at] realvnc
To remove yourself from the list visit: