| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Use the new "override" keyword to properly differentiate between new
virtual methods, and existing virtual methods being overridden.
|
| |
|
|
|
|
| |
Since 53f913a we initialize the underlying PixelBuffer with 0x0
dimensions, which means we need to keep more explicit track of what
we are trying to allocate in the setup methods.
|
| | |
|
| |
|
|
| |
This will allow us to render more things than just the framebuffer.
|
| |
|
|
|
| |
The complex logic waiting for events didn't result in any added
performance, so use the simpler approach.
|
| |
|
|
|
| |
We need to make sure the display server has finished reading our
previous update before we overwrite the buffer with the next update.
|
| |
|
|
|
| |
The damage tracking region needs to be protected from multiple
threads accessing it at once. The rest should be fine though.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
It was confusing and not properly used everywhere.
Callers should use the stride they get when they get
the buffer pointer.
|
| |
|
|
|
| |
This allows us to gracefully fall back to the FLTK code in case the
platform specific code cannot be used.
|
|
|
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4492 3789f03b-4d11-0410-bbf8-ca57d06f2519
|
