removed no more actually used count property of BITMAP_UPDATE struct,
fixed allocating twice as memory for its rectangles - as of refactoring
at e5767f07 BITMAP_UPDATE struct is reused no more
When uploading large ICON (96x96), we end up growing the stream
mid-update. Stream_EnsureCapacity end up reallocating the stream
with a larger capacity to accomodate the large ICON size, but in
doing so, also updating the sealed length for the data currently in
the stream. This breaks the assumption between update_begin_paint
and update_end_paint where the sealed lenght is used to keep track
of the location where we need to update the orders counts after
we're done accumulating update. As a result of the growth and lost
of that location, the number of orders is written to the wrong
location and the resulting stream is invalid which result in a
protocol violation and a connection drop.
The current fix uses a new offsetOrder in the update object to
keep track of where update_end_paint needs to write the number
of orders contained. I think a better fix would be for
Stream_EnsureCapacity to preserve the sealead length of the
stream on growth, but this has a much more significant impact and
careful analysis needs to be done to ensure this doesn't violate
other assumption. Need to follow up with FreeRDP developer to get
their take on this one.
* Pass on proper command type to application
* On send let the server implementation decide to send
2.2.9.2.1 Set Surface Bits Command (TS_SURFCMD_SET_SURF_BITS) or
2.2.9.2.2 Stream Surface Bits Command (TS_SURFCMD_STREAM_SURF_BITS)
Thanks to @viniciusjarina for tracing the issue down.
Since these functions were called from 2 different threads
(main thread or dynamic channel) depending on fastpath or
gfx channel use lock between these.
If not locked the invalid region may be accessed from both
threads and lead to crashes as experienced with nightly df280a7ff
This patch adds some callbacks so that the client can have access to the informations
stored in this packet. Server-side implementation is also there, so that a server
can send these informations to the client.
- clients will need this to present the offscreen to the display
in the correct state in order to avoid flickering and artefacts
and to do frame acknowledgement.
- added empty callback to xfreerdp.
