Skip to content
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

Merged
merged 2 commits into from
May 25, 2021

Conversation

pnowack
Copy link
Member

@pnowack pnowack commented May 24, 2021

Quoting the main commit here:

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.

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)

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.
@freerdp-bot
Copy link

Can one of the admins verify this patch?

Copy link
Member

@akallabeth akallabeth left a 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.
@pnowack pnowack force-pushed the gfx-progressive-mthreaded branch from f47ae23 to e79fefe Compare May 25, 2021 07:38
@akallabeth akallabeth added this to the next milestone May 25, 2021
@akallabeth
Copy link
Member

@freerdp-bot test

@freerdp-bot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://ci.freerdp.com//job/PullRequestTester/5967/

@akallabeth akallabeth merged commit e8d146b into FreeRDP:master May 25, 2021
@akallabeth
Copy link
Member

thanks for this fix, really appreciated :)

@pnowack pnowack deleted the gfx-progressive-mthreaded branch July 15, 2022 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants