-
Notifications
You must be signed in to change notification settings - Fork 14.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
codec/progressive: Allow the usage of multithreading for decoding #7036
Conversation
When checking whether tiles and updatedTileIndices are both non-NULL, one of them might be NULL, while the other struct member might not be NULL and progressive_surface_context_new() leaks then the non-NULL struct member. Fix this by freeing both struct members, when aborting in progressive_surface_context_new(). free() will take no action on pointers that are NULL, so no additional check is needed.
Can one of the admins verify this patch? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM, just maybe remove the code duplication for the single threaded path.
While decoding RemoteFX encoded frames is multithreaded, decoding RemoteFX Progressive frames is not, although both codecs work relatively similarly. This is especially noticeable with frames, that have a resolution larger than 1920x1080 pixels. decompress_tile_first() and decompress_tile_upgrade() can both run in different threads at the same time for different tiles without necessary adjustments. So, do exactly that using the ThreadPool that already exists in the RFX_CONTEXT to decrease the decoding time and therefore increase the performance. On a 3K display (2880x1620 pixels) this makes out of a choppy experience a fluid experience.
f47ae23
to
e79fefe
Compare
@freerdp-bot test |
Refer to this link for build results (access rights to CI server needed): |
thanks for this fix, really appreciated :) |
Quoting the main commit here:
This fixes a heavy performance regression with the RemoteFX Progressive codec, which the plain RemoteFX codec (when using the graphics pipeline) does not have.
I have tested this on top of the stable-2.0 branch using gnome-remote-desktop (uses TILE_SIMPLE) and Win10 (use TILE_FIRST + TILE_UPGRADE)