A single display update can now result in multiple commands / update
code (FastPathUpdate).
The update dispatching and bitmap encoding is now done by the
UpdateEncoder itself.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Trying to share a common buffer creates all sort of complicated lifetime
issues when trying to move the encoding to a 'static handler, or when
implementing iterators. It's not worth it.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
It should reflect client drawing state.
In following changes, we will fix it to draw bitmap updates on it, to
keep it up to date.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The bitmap encoder dispatching code was becoming convoluted and the same
struct was handling PduEncoding and various bitmap encoding handling.
Instead, split UpdateEncoder in different types and concerns.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Dealing with multiple formats is sufficiently annoying, there isn't much
need for awkward image layout. This was done for efficiency reason for
bitmap encoding, but bitmap is really inefficient anyway and very few
servers will actually provide bottom to top images (except with GL/GPU
textures, but this is not in scope yet).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As written in the workspace Cargo.toml:
> Note that for better cross-tooling interactions, do not use workspace
dependencies for anything that is not "workspace internal" (e.g.: mostly
dev-dependencies). E.g.: release-plz can’t detect that a dependency has
been
updated in a way warranting a version bump in the dependant if no commit
is
touching a file associated to the crate. It is technically okay to use
that
for "private" (i.e.: not used in the public API) dependencies too, but
we
still want to make follow-up releases to stay up to date with the
community,
even for private dependencies.
Expectation is that release-plz will be able to auto-detect when bumping
dependents is necessary.
Closes#689
It's problematic when the client didn't resize, as we send bitmap
updates that don't fit. The client will likely drop the connection.
Let's have a warning for this case in the server.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This makes freerdp keep the flag up and handle desktop
resize/deactivation-reactivation. It should be okay to advertize,
if the server doesn't resize anyway, I guess.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
I couldn't find any explicit behaviour described in the specification,
but apparently, we must just keep the channel state as they were during
reactivation. This fixes various state issues during client resize.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The current behaviour of handling unmatched PDUs in fn read_by_hint()
isn't good enough. An unexpected PDUs may be received and fail to be
decoded during Acceptor::step().
Change the code to simply drop unexpected PDUs (as opposed to attempting
to replay the unmatched leftover, which isn't clearly needed)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This can help a lot wall-clock time, but depends on CPU.
rfx_enc time: [9.7885 ms 10.123 ms 10.439 ms]
change: [-80.484% -79.847% -79.208%] (p = 0.00 < 0.05)
Performance has improved.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
