tigervnc.git - High performance, multi-platform VNC client and server: https://github.com/TigerVNC/tigervnc

	Commit message (Collapse)	Author	Age	Files	Lines
*	Fix for exception handling in decoder threads	Pierre Ossman	2017-02-22	1	-1/+1
\|
*	Optimised shortcut for decoding on single CPU systems	Pierre Ossman	2015-11-27	1	-1/+17
\|
*	Limit the number of decoder threads to 4	Pierre Ossman	2015-11-27	1	-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 thread	Pierre Ossman	2015-11-27	1	-2/+35
\|
*	Create one decode thread for each CPU	Pierre Ossman	2015-11-27	1	-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 decoding	Pierre Ossman	2015-11-27	1	-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 needed	Pierre Ossman	2015-11-27	1	-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 order	Pierre Ossman	2015-11-27	1	-3/+20
\|
*	Make the decoder multi-threaded	Pierre Ossman	2015-11-27	1	-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 step	Pierre Ossman	2015-11-27	1	-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 CConnection	Pierre Ossman	2015-11-27	1	-2/+3
\|
*	Delegate decoder object management to a separate class	Pierre Ossman	2015-11-27	1	-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.