| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Our XRender code assumes a certain pixel layout which was not
guaranteed on big endian systems. The previous workaround only worked
for some cases, so fix this properly now.
|
| | |
|
| | |
|
| |
|
|
| |
Everyone else seems to get by with using 0600, so let's do the same.
|
| |
|
|
|
| |
It's not enough that we detach from the shared memory, we must also
tell the X server to do so for it to be freed properly.
|
| |
|
|
| |
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.
|
