| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
The reason for this is to keep a consistency through out the project.
|
|
|
|
|
| |
It's a source of confusion and possibly bugs to reuse the same variable
name for multiple things.
|
|
|
|
|
| |
It's more readable than 0, and a bit safer than NULL, so let's try to
follow modern norms.
|
|
|
|
|
| |
Avoid having our own custom stuff and instead use the modern, standard
types, for familiarity.
|
|
|
|
|
| |
Avoid preprocessor magic and instead rely on templating to generate
optimized functions for performance critical code.
|
|
|
|
|
| |
This allows us to separate accidentally unused, from explicitly unused
parameters, which allows us to turn on such checks in the compiler.
|
|
|
|
| |
They have no need for it, so let's simplify things.
|
|
|
|
|
|
| |
The generally recommended way is to include it from source files, not
headers. We had a mix of both. Let's try to be consistent and follow the
recommended way.
|
|
|
|
|
| |
The principle can be used in a more general fashion than just TCP
streams.
|
|
|
|
|
|
| |
Now that we've split out server state to ServerParams, ConnParams
only contains state for a client. Rename the class and variables
to reflect this.
|
| |
|
|
|
|
|
| |
Either by casting, or switching to a more appropriate type
for the variable.
|
| |
|
|
|
|
|
|
|
|
| |
This allows us to apply a lot more server logic
independently of which encoder is in use.
Most of this class are things moved over from the
Tight encoder.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
The connection object is a much more appropriate object for the
decoders and encoders to keep track of. Besides the streams, it also
contains state like connection parameters.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Keep the generic stream classes clean and general.
|
| |
|
|
|
|
|
|
| |
Get rid of the ability of encoders to only send part of the
rectangle they are given as we don't want partial updates
anyway.
|
|
|
|
| |
We have no need for this abstraction so let's keep things simple.
|
| |
|
|
|
|
| |
We have no use for it, so let's keep things simple.
|
| |
|
|
|
|
|
|
| |
always uses the raw buffer, which is not true. If pixel translation is necessary, then JPEG images will sometimes be encoded from the translated (intermediate) buffer instead.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4852 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
|
|
|
| |
work so well with the new optimisation to feed it the raw frame buffer.
Reorganise and clean up the code to handle this, and make the raw frame
buffer pointer const so that we might avoid such bugs in the future.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4841 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
|
|
| |
(bandwidth is often the limiting factor, rather than CPU). Further increases
give little returns, so 2 is currently deemed the best tradeoff.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4811 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
| |
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4752 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
| |
that, when a TurboVNC viewer is connected, the TigerVNC Server will behave exactly like the TurboVNC Server.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4641 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
| |
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4638 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
| |
The encoder now directly accesses the framebuffer for solid rectangle computation, JPEG encoding, and color counting (if pixel translation is not required.) Also moved everything in tightEncode.h into the TightEncoder class to eliminate all of the static mess (this will be important later on if we decide to multi-thread the encoder.)
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4631 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
| |
parameters were determined through extensive low-level profiling (see http://www.virtualgl.org/pmwiki/uploads/About/turbototiger.pdf). The other enhancements involved: (1) porting the solid subrectangle pre-computation code from TightVNC/TurboVNC (it makes a pretty big difference-- see report), (2) encapsulating the JPEG encoder in its own class (this eliminates a buffer copy, and the JPEG buffer is now set to a decent size where it shouldn't ever need to be paged or re-allocated, except in rare corner cases), (3) adding support for last rect. encoding (necessary to support the solid rectangle pre-computation enhancements.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4626 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
| |
ratios, as defined by the VirtualGL project study of rendered frames from SPECviewperf 9
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3666 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
|
|
|
|
|
|
|
| |
The percieved quality isn't really linear compared to the actual quality
setting, so make it a bit more top heavy. Also disable color subsampling
at some levels and make the highest quality lossless.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@3660 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
|
More changes will follow.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@589 3789f03b-4d11-0410-bbf8-ca57d06f2519
|