We now filter incoming data, which means we can start assuming the
clipboard data is always null terminated. This allows us to clean
up a lot of the internal handling.
We should start by getting the remote end in sync with the actual
keyboard state. This would work randomly before depending on if we
got the first LED state message before or after we got focus.
We don't want to surprise the user with unexpected clipboard changes
when vncviewer is in the background, and it is both wasteful and
possibly insecure to inform the server of every clipboard update
when the user isn't interacting with it.
Try to properly detect the fake CtrlL+AltR sequence Windows sends
when pressing AltGr. This allows us to send more accurate key
events over to the server.
Some platforms draw directly to the screen, which means that updates
will flicker if we draw multiple layers. Prevent this by first
composing the update on a hidden surface.
Delegate decoder object management to a separate class
Done in preparation for multi-core decoding. Keeps the complexity
out of the other classes. This also moves ownership of the
framebuffer in to CConnection. It's the CConnection object that is
aware of the threads and how to synchronise with them. Therefore
the ownership of the framebuffer must also be there to make sure
it isn't deleted whilst threads are working.
Use PixelBuffer objects as the interface for encoders and decoders
This avoid a lot of unnecessary middle men. This also pushes the
responsibility for pixel format conversion into the encoders and
decoders. The new bufferFromBuffer() is used for direct conversion,
rather than PixelTransformer/TransImageGetter.
Gets rid of a loooot of code and complexity.
Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.
If the client and server are using identical pixel formats, then perform Tight decoding directly into the viewer's back buffer, rather than going through the slow fillRect/imageRect routines.
- Changes behaviour of context menu to be reinitialize
before display with intial states.
- Fixes for fullscreen contextmenu item to show the
current fullscreen state as it was done in the
old viewer.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4670 3789f03b-4d11-0410-bbf8-ca57d06f2519
The new viewer stores the framebuffer in a native format, instead of
converting it on each render like the old one. That means we have to change
how we deal with colour maps and make sure it is updated before any changes
to the framebuffer.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4589 3789f03b-4d11-0410-bbf8-ca57d06f2519
Implement optimised drawing operations for OS X. Didn't see any reduction in
CPU usage unfortunately, but at least we're now using the native pixel format
of our server which avoids a conversion on the server side.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4504 3789f03b-4d11-0410-bbf8-ca57d06f2519
Flushing screen updates after 100 ms turned out to be too aggressive and
just gave an annoying window blinds effect that made things difficult to
read. Reduce things to 500 ms, which should be sufficient to tell that the
session isn't completely frozen.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4495 3789f03b-4d11-0410-bbf8-ca57d06f2519
Handling a full range of keys for the menu key is not as trivial in FLTK as
with raw X11, so do what the Windows client did and restrict the available
keys to just the function keys.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4444 3789f03b-4d11-0410-bbf8-ca57d06f2519
Reorganise the translation to keysyms to make the code simpler. At the same
time give special keys priority as some of them generate symbols as well.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4355 3789f03b-4d11-0410-bbf8-ca57d06f2519
Pierre Ossman
DRC
Henrik Andersson