When issuing tile render requests proactively (upon
getting invalidatetile event), if the registered
request has no subscriber, TileCache::saveTileAndNotify
simply drops the tiles!
New call sequence:
ClientSession::handleTileInvalidation
docBroker->handleTileCombinedRequest
tileCache().subscribeToTileRendering //< fix
The end result was that we rendered tiles only
to discard them, potentially leaving the clients with
stale tiles (unless they requested new tiles themselves).
If they do request them, we still benefit from the cached
copies of the internal requests we had issued (and dropped).
The issue is that we are wasting an opportunity for efficiency
and relying on the client to request tiles when we normally
push on invalidation, adding latency and being inconsistent.
Change-Id: I4d3aa3739c5324ffca15c80b20dce29ac03eef73
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
The old code worked for "gcc -fsanitize=address", but the sanitizers
tinderbox builds with "clang -fsanitize=address".
Follow-up to commit f67b8901dd (test:
double the timeout in isDocumentLoaded() for sanitizers, 2021-11-03).
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I4b802ec0d3d20516e3d58cc1c65d7e1422632b2b
Created trace for adding and editing slides and shapes in Impress. Also re-typing and adding bullet points using large Writer file
Signed-off-by: Nnamani Ezinne Martina <nnamani.ezinne@collabora.com>
Change-Id: I3541295fada230338acb934409c2bcb80730354b
Signed-off-by: Nnamani Ezinne Martina <nnamani.ezinne@collabora.com>
The sanitizers tinderbox regularly times out, and it's good to know if
the timeout value is an agressive one or the load is really that slow.
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I2903481ea9efde68aca3f4ec00bd6e7e2d3b840a
SteamSocket::eraseFirstInputBytes() removes from the beginning
of std::vector, which is generally slow. If the buffer becomes
too big, which it may under a load, then the function will get
slow, which in turn will likely lead to the buffer getting even
bigger because of accumulated backlog.
The Buffer class is optimized for removal at the beginning,
so use it instead of std::vector, including some API additions
for it to be an in-place replacement where it's used.
Signed-off-by: Luboš Luňák <l.lunak@collabora.com>
Change-Id: I4cf7ec56c908c7d3df391dc3f8e230ad32abb162
The startsWith method that receives a StringToken was doing a bounds
check on the wrong parameter. This caused most calls to return false.
This commit adds some tests to both versions of StringVector::startsWith.
Signed-off-by: Hugo Peixoto <hugo.peixoto@gmail.com>
Change-Id: Icd4c648d681723ac66dba3c6a42ab7920850c619
Using mobile device, created traces for text document, Spreadsheet and Impress files in real editing sessions
Signed-off-by: Nnamani Ezinne Martina <nnamani.ezinne@collabora.com>
Change-Id: Ie1afa80b87963999a5a3520d67fb411624b7fdc9
Created traces for text document, Spreadsheet and Impress files using real editing sessions
Signed-off-by: Nnamani Ezinne Martina <nnamani.ezinne@collabora.com>
Change-Id: I99e290b1cc9c2d14e1341a211190d7d2a64b2ea4
test/lokassert.hpp:16:22: note: 'operator<<' should be declared prior to the call site
Change-Id: I7533490e64b1181b3349d0966b42eba4dcc88f05
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
This adds a new service render-search-result, which renders an
image of the position where, the search fund a hit. The search
result contains the information in which object or paragraph,
which is just the node id and node type from the document model.
The service takes the document and the search result (xml file)
as the input and returns a PNG image as the output.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Iffc158c5b0a3c9a63f8d05830314c9bc1616b3b1
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
This can happen on an assertion failure, and causes noise while looking
for real memory errors.
Also disable an unstable test, it's not clear that it passes depending
on how loaded the machine is (just increasing timeouts doesn't seem to
help).
Signed-off-by: Miklos Vajna <vmiklos@collabora.com>
Change-Id: I049bd0a06f41e2d43702ec12a2c35944bc5200d8
So it can be easy to analyze the backtrace of the
failing assertion.
Change-Id: Icdcf55b1404f858eba1d499bd65719a0e2da21db
Signed-off-by: Henry Castro <hcastro@collabora.com>
Otherwise the unit test will take too much time
to fail.
Change-Id: I9a85a79ad2ced5d220394cdf71a7f703265e50ef
Signed-off-by: Henry Castro <hcastro@collabora.com>
if make is killed or interrupted during the execution
of their recipes, the target is not deleted. So there is
an opportunity to check the logs, why are taking to long
time to finish the test.
Change-Id: I6e8176a48ff721ecb2b2efc01b1f149907dd359b
Signed-off-by: Henry Castro <hcastro@collabora.com>
At least I didn't fully understand what the old code actually was
checking.
Also, use sizeof instead of magic numbers.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I01602a2e256b1fbe39793c9f1439e025461c5a72
Our JS code does not send 'textinput' messages with a 'type' parameter
either, so it is pointless to do it in a unit test.
(We still have code that checks for the 'type' parameter in received
'textinput' messages. That is pointless, too, and should be removed.)
Also, document what testWriterTyping() apparently is doing.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I4954379339f14e4a310a76788521001048d84e37
