aboutsummaryrefslogtreecommitdiffstats
path: root/common/rfb/DecodeManager.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Don't wrap exceptions from readRect()Pierre Ossman2025-03-131-6/+2
| | | | | | | | This is a revert of 0ce9fef. The object slicing is causing issues, e.g. when we get a completely expected end_of_stream exception. It's unclear what exceptions we needed this wrapping for. We'll just have to remove it and see what problems we encounter.
* Use std::exception_ptr to store exceptionsPierre Ossman2025-03-131-14/+11
| | | | This is much more robust and flexible than what we came up with.
* Move concurrency abstration layer to corePierre Ossman2025-02-251-9/+8
| | | | | OS abstractions are generic enough that we can merge these with the new core library.
* Rename core/util to core/stringPierre Ossman2025-02-251-1/+1
| | | | | It's just string helper functions here, so let's get rid of the catch-all name for this module.
* Move logging to core libraryPierre Ossman2025-02-251-2/+2
| | | | | | | Make it clearer what is protocol handling and what is just general plumbing. This is one step of several.
* Move base exception classes to core libraryPierre Ossman2025-02-251-1/+0
| | | | | | | Make it clearer what is protocol handling and what is just general plumbing. This is one step of several.
* Move utility functions to core libraryPierre Ossman2025-02-131-9/+10
| | | | | | | Make it clearer what is protocol handling and what is just general plumbing. This is one step of several.
* Move basic data types to core libraryPierre Ossman2025-02-131-3/+4
| | | | | | | Make it clearer what is protocol handling and what is just general plumbing. This is one step of several.
* Don't save exceptions as std::exceptionPierre Ossman2024-11-261-1/+1
| | | | | | That type is not guaranteed to preserve anything useful at all. Instead, try to either preserve a more specific type, or use std::runtime_error which at least has a guaranteed message.
* Use standard library naming for exceptionsPierre Ossman2024-11-061-2/+2
| | | | | This makes things more consistent since we mix with the standard library exceptions so often.
* Use specific class for protocol problemsPierre Ossman2024-11-061-2/+2
| | | | Make it easier to identify communication issues.
* Use standard exception classesPierre Ossman2024-11-061-2/+2
| | | | | Use the more specific already included exception classes for common errors to keep things more understandable.
* Subclass exceptions from std::exceptionPierre Ossman2024-11-061-4/+4
| | | | | Make sure our exceptions are part of the standard exception class hierarchy.
* Use what() to access exception descriptionPierre Ossman2024-11-061-2/+2
| | | | Harmonize with the standard C++ exceptions.
* Use static string for exceptionsPierre Ossman2024-11-061-2/+2
| | | | | In preparation for using the built in C++ exception classes, which do not accept a format string.
* Avoid shadowing variablesPierre Ossman2024-06-241-7/+4
| | | | | It's a source of confusion and possibly bugs to reuse the same variable name for multiple things.
* Simplify code using range-based for loopsPierre Ossman2024-06-241-19/+14
| | | | | | | | | These are often more readable as they avoid a lot of the boilerplate of iterating over fixed arrays or STL containers. Note that this change is very conservative to avoid noise in "git blame". Only loops where this is a clear improvement have been converted.
* Use nullptr in all C++ codePierre Ossman2024-06-241-8/+8
| | | | | It's more readable than 0, and a bit safer than NULL, so let's try to follow modern norms.
* Remove unused rfb/util.h includesPierre Ossman2023-02-041-1/+1
| | | | | | | | These files don't use anything from this header, so remove the include. This exposes some missing includes in other places, though. So add an explicit include in the files that were relying on an indirect inclusion.
* Return std::string instead of dynamic allocationsPierre Ossman2023-02-041-12/+9
| | | | | | We mostly use classical C strings, but the memory management around them can get confusing and error prone. Let's use std::string for the cases where we need to return a newly allocated string.
* Be consistent in including config.hPierre Ossman2021-12-301-0/+4
| | | | | | 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.
* Log decoding stats on disconnectPierre Ossman2021-11-041-0/+55
| | | | | Can be helpful to see what encodings were actually used during a connection, and how they performed.
* Throw more descriptive error on rect read errorPierre Ossman2021-11-041-2/+6
| | | | Gives a bit more context where this error happened.
* Remove single cpu decoder shortcutPierre Ossman2021-11-041-27/+1
| | | | | Single CPU machines are extremely rare now, so let's avoid the hassle of multiple code paths.
* Change streams to be asynchronousPierre Ossman2020-05-211-4/+9
| | | | | | | | | | Major restructuring of how streams work. Neither input nor output streams are now blocking. This avoids stalling the rest of the client or server when a peer is slow or unresponsive. Note that this puts an extra burden on users of streams to make sure they are allowed to do their work once the underlying transports are ready (e.g. monitoring fds).
* Throw more descriptive error on decode errorPierre Ossman2020-05-211-2/+7
| | | | We need to be able to tell this exception came from a decoder.
* Split out ServerParams from ConnParamsPierre Ossman2018-11-011-7/+7
| | | | | | We need to track different things in the server and client, so separate things to two independent structures to keep things more clear.
* Catch exceptions by referencePierre Ossman2018-05-291-1/+1
| | | | | We use polymorphic exception objects, so catching by value invokes the copy constructor and stuff that we don't really want.
* Avoid creating unused thread on single CPU machinesPeter Åstrand (astrand)2018-05-071-1/+7
|
* Fix for exception handling in decoder threadsPierre Ossman2017-02-221-1/+1
|
* Optimised shortcut for decoding on single CPU systemsPierre Ossman2015-11-271-1/+17
|
* Limit the number of decoder threads to 4Pierre Ossman2015-11-271-1/+6
| | | | | They just end up burning CPU fighting each other without much improvement to the decoding time beyond four threads.
* Propagate exceptions from worker threads back to main threadPierre Ossman2015-11-271-2/+35
|
* Create one decode thread for each CPUPierre Ossman2015-11-271-4/+10
| | | | | | We can start creating more decoding threads now that we handle rect ordering properly. No point in creating more threads than there are CPUs though.
* Allow conditional dependencies between rects when decodingPierre Ossman2015-11-271-0/+17
| | | | | | Some encodings only cause dependencies between rects some of the time. Make sure we can allow parallel decoding of those rect that aren't dependent on each other.
* Decode rectangles in order if neededPierre Ossman2015-11-271-2/+11
| | | | | Some encodings must be handled in the order they are received. Make sure we respect this in the decode manager.
* Decode overlapping rectangles in orderPierre Ossman2015-11-271-3/+20
|
* Make the decoder multi-threadedPierre Ossman2015-11-271-7/+190
| | | | | | | This implements the basic infrastructure for multi-threaded decoding of rects. However there is just one thread reading data and one thread decoding it. More logic is needed to safely decode multiple rects at the same time.
* Split decoders into a read and decode stepPierre Ossman2015-11-271-1/+10
| | | | | | | | We need to split these steps up in preparation for multi-core support. Reading needs to be done in a serial manner, whilst decoding can be done in parallel. This also involved a rather large cleanup of the Tight decoder.
* Decouple decoders from CConnectionPierre Ossman2015-11-271-2/+3
|
* Delegate decoder object management to a separate classPierre Ossman2015-11-271-0/+63
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.
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-12 13:01:26 +0000