The new delta messsage feature expects PNG data to be unencoded or zstd
compressed only.
Signed-off-by: Patrick Luby <patrick.luby@collabora.com>
Change-Id: I776fb8e79fc9617edc5178ec66d6f0bac0706c71
Squashed from feature/deltas-expanded.
TileCache changes:
+ add montonic sequence (wid) numbers to TileData
+ account for sizes of TileData with multiple blobs
+ simplify saving and notifying of tiles
Sends updates (via appendChanges) based on the sequence the
right mix of keyframes and/or deltas required as a single
message, and parse and apply those on the JS side.
We continue to use PNG for slide previews and dialogs,
but remove PngCache - used by document tiles only.
Annotates delta: properly as a binary package for the websocket.
Distinguishes between deltas and keyframes we get from
the Kit based on an initial un-compressed prefix
character which we then discard.
kit can be forced to render a keyframe by oldWid=0
Track invalidity on tiles themselves - to keep the keyframe around.
We need to be able to track that a tile is invalid, and so subscribe
to the updated version as/when it is ready - but we also want to
store the keyframe underneath any deltas.
force rendering of a keyframe for an empty slot in the TileCache.
force tile sequence to be zero for combinedtiles - so the client can
always request standalone tiles with explicit combinedtiles, or tile
requests.
move Blob to Common.hpp
use zero size for un-changed tiles.
remove obsolete render-id, and color deltas in debug mode.
cleanup unit tests for non-png tile results.
Change-Id: I987f84ac4e58004758a243c233b19a6f0d60f8c2
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Also, makes the logging of units much less error prone.
The overloaded streaming operators are temporary as
they are provided in C++20. The ones here (though
incomplete) are fashioned after the C++20 specs.
Change-Id: Ieb499282ccb6e63fa939ba07bed3e5a4fbef1bd0
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
LibreOffice core uses that, too, and we support an even more
restricted set of compilers.
Change-Id: I0d0e2c8608e323eb5ef0f35ee8c46d02ab49a745
Reviewed-on: https://gerrit.libreoffice.org/c/online/+/92467
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Sometimes core renderes with sub-pixel differences
(the crosshair at the corners of the Writer pages
show line anti-aliasing differences). This causes
failure of the tests that count the tile deduplication.
We now tolerate when we get an unchanged tile twice,
assuming it was due to such a rendering difference,
but we re-trigger another change and this time we
don't expect any extra tiles, no more than two
variations of the anti-aliased crosshair was
observed.
We also move some duplicate code into utility
functions to improve readability and reuse.
Reviewed-on: https://gerrit.libreoffice.org/81196
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 9603597fd1aaecb27893792cfd2d243e450b58b8)
Change-Id: I1a66732dd3443bfbd770d8dc65721571dfa08615
Reviewed-on: https://gerrit.libreoffice.org/81572
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
As the comment details, this avoids having C++ objects
in the same frame as setjmp, which may reset their
contents without the dtor getting called.
Change-Id: I851ae8bffb4356d465a25dfc815a1fecb489fa30
Reviewed-on: https://gerrit.libreoffice.org/79338
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
The default deflate level of 6 is quite slow
and the benefits are hardly worth the high
latency that users experience.
Tested on a writer document with some small
images and a few pages of text:
Level 4 gives virtually identical compression
ratio to level 6, but is between 5-10% faster.
Level 3 runs almost twice as fast as level 6,
but the output is typically 2-3x larger.
Perhaps this should be exposed via config
so it would be possible to reduce latency
due to compression when CPU is scarce but
network bandwidth ample, and vice versa.
Change-Id: Iba88eea8f180d11458b33c68389e797234df1a60
Reviewed-on: https://gerrit.libreoffice.org/71018
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
(What we cache is also the textual data: URLs even if we store them
using .png file names.)
This avoids the current back-and-forth-encoding: First we
base64-encode the complete binary "tile:" message (one text line
followed by a newline and the binary PNG) to pass to WebKit, then in
the JavaScript snippet passed to WebKit we decode the base64 and turn
it into an ArrayBuffer, and then we unpack the ArrayBuffer and encode
the PNG part to use as a data: URL.
As far as I see, we tend to use the same namespace name as the
basename of the corresponding include file, and this stuff is defined
in a file called Png.hpp.
Change-Id: Id859e13e94568abd9f1d5b4ef3bfbbb0c156db11
and apply the nullptr plugin.
Lots of hacking in my LO tree required to make this work, will probably
end up needing to add an extra parameter to the LO side.
Change-Id: I02ae1dcdece9d9ddf05f7757f6696e3a5d7d1f14
Reviewed-on: https://gerrit.libreoffice.org/32339
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
We need a fast and good (high avalanche properties)
hash function for the png caching to avoid collissions
(even in the very limited samples we have, since tiles
are likely to have patters, such as all 0's and all 1's
etc.).
Bob Jenkins's public domain SpookyV2 is used here.
It has great avalanache properties and is fast at
~3-bytes / cycle for large messages.
Only trailing whitespace was removed from original
sources and 4 tabs converted to spaces.
Change-Id: Ife57237321625c836d85c894d939fd04a8f577bb
Reviewed-on: https://gerrit.libreoffice.org/31292
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
