So we can avoid that tile sending stop working because server is
waiting for tileprocessed messages which will not arrive.
Change-Id: I545346c50d49340999608aadac32b5190ede43c5
A problem comes up when only a part of the tile is visible
on the client side and invalidation affects the invisible
part of this tile. To get back the old / right behavior we
need to request this kind of tiles too.
This reverts commit f1a385be98.
It's not easy, it can interfere the tile tracking.
Change-Id: I1e4ec9b4d66e5e912873f673fd5cb71ba55a9332
Reviewed-on: https://gerrit.libreoffice.org/59326
Reviewed-by: Tamás Zolnai <tamas.zolnai@collabora.com>
Tested-by: Tamás Zolnai <tamas.zolnai@collabora.com>
No need to keep such a cache here. The consumer of previews
(thumbnails) in question does it itself (Nextcloud).
This reverts commit 405b66c8db
Change-Id: Iad16212ccbc875fe4f6d041e2fceef7eaea1d1bb
Store the tile cache names and drop outdated tiles
times to times, so we can avoid tile rendering / sending to
stuck.
Change-Id: Ibff001307c7c660cbc57ab20c29c430e0090444d
I used number 25 as this limit. It's an approximate value. It's enough
to handle the first 5-10 character input without waiting for tileprocessed
messages. After the first 5-10 characters the tileprocessed messages are
arriving continuously (same frequency as the typing speed), so for the later
character inputs we always have some tileprocessed messages arrived so
we can push new tiles to the network again.
This 25 upper limit also seems enough to send all tiles when a whole page is
requested (e.g. zoom os scroll).
We store the requested tiles in a list, used as a queue. I don't use std::queue
because sometimes we need to do deduplication (replace older versions of the
same tile with a newer version).
Change-Id: I22ff3e35c8ded6001c7fc160abdc1f1b12ce3bae
We always one bunch of tiles (e.g. all tiles invalidated) and we
are waiting until client send tileprocessed message back for all
tiles before sending the new tiles.
By canceltiles message we drop every previously requested tiles and
make wsd ready to send new tiles, which will be requested by the client
in theory.
Change-Id: I9901420ada549e962ffaf5e6bd58e52b86bd129d
When asked to "convert" a document to a PNG image, i.e. what one can
call a thumbnail, check if we have a cached PNG for the same docuemnt
already, and in that case return it.
When we have done such a convert-to operation to PNG, save the result
in the cache for later re-use.
This change adds no thumbnail cache cleanup mechanism. That will have
to be implemented separately using a cron job or whatever.
There are further improvement possibilities: For instance, if the
document is of a type that contains an embedded thumbnail (like ODF),
just extract and return that. For ODF that embedded thumbnail even
already is in PNG format.
Change-Id: I882efe97acc1d81041dc7a4ccb222995940e4836
Reviewed-on: https://gerrit.libreoffice.org/57345
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Log all error: cases in ClientSession::handleKitToClientMessage(), not
just the case of cmd=load with kind= some password failure.
Change-Id: I53c959068f5642ae41157e8feb14fd34fc59dc9a
Since changing the tracking state is done by toggling,
we need to wait to get the current state at load time
before we can tell whether we need to toggle it or not.
Change-Id: Ib5a2639b2acf3874c191971eedf9a3bebcefebad
Reviewed-on: https://gerrit.libreoffice.org/53415
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
Tested-by: Jan Holesovsky <kendy@collabora.com>
Otherwise saving is bound to fail, causing other
errors, which is nonsensical since there is nothing
to save to begin with.
Change-Id: Icb65a4a3b277b3175aadbe5107b294b24a399e7b
Reviewed-on: https://gerrit.libreoffice.org/50148
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Asking the doc broker to close means that it will save the current
document to storage before shutting down. But we don't want that because
storing the current document to storage means overwriting the document
which has been changed underneath us.
Change-Id: I8df45d2f0cf3f65936dc3030f483e52fd1703146
Reviewed-on: https://gerrit.libreoffice.org/49134
Reviewed-by: pranavk <pranavk@collabora.co.uk>
Tested-by: pranavk <pranavk@collabora.co.uk>
Now always given a proper reason too.
Also, stop polling thread and cleanup when
failing to acquire/spawn a child process.
Change-Id: I7ddee01dd47b8ee72f2d9134c0f1b264634d8611
Reviewed-on: https://gerrit.libreoffice.org/47886
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Maintaining a flag is problematic, at least the way
it was reset on adding new sessions. Luckily there
should be no reason for having it, since we should
check it only when removing sessions. Also, we
need to check for every case of removal, and not, as
was, just on disconnection, which is incomplete.
Change-Id: I878766701228c41fc93eeaff21852fa887de9eff
Reviewed-on: https://gerrit.libreoffice.org/47883
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
use a specific message from the client for set the visibility state of
a group instead of hijacking the update row/column header message
Change-Id: I69d66b30db0b4d8a0082cbd2524120491d4f97cb
Reviewed-on: https://gerrit.libreoffice.org/45446
Reviewed-by: Marco Cecchetti <mrcekets@gmail.com>
Tested-by: Marco Cecchetti <mrcekets@gmail.com>
