Basically, instead of foo.compare(0, 3, "bar") use
LOOLProtocol::getFirstToken(foo)!="bar". Using a separate length of a
string literal is very fragile, it is easy to get the length wrong, or
forget to change it in case the string changes. See
137e677eb0.
It isn't entirely sure to me whether was is kept in a message queue
follows LOOL protocol message syntax, but it seems to be so in
practice, so we can use LOOLProtocol::getFirstToken().
Also, calls like msg.compare(0, 4, "tile") add undocumented implicit
requirements that the token in question must be unique as an initial
substring of the first tokens of all messages. It actually isn't,
there is also "tilecombine". But in this case, that was taken care of
by checking for "tilecombine" first. Ugh. Whether that was by accident
or design is hard to say, but at least there was no comment indicating
intentionality.
We still have lots of similar fragile mis-use of std::string::find().
Tokenizes a string and looks for the requested named parameter (in the
form name=value, like the other getToken* functions).
Also add a unit test for the getToken* functions.
I got:
httpwstest.cpp:2198:Assertion
Test name: HTTPWSTest::testCursorPosition
equality assertion failed
- Expected: 1418
- Actual : 1425
If we want exact equality, then the underlying difference has to be
fixed first.
Change-Id: I82600fc738ca0923d81d1b59521e1a46167bb781
Combining as much as possible is too aggressive and
seems to harm performance where large areas are
invalidated during editing (f.e. inserting text
at the begining of a paragraph).
With this patch we only combine a single row at a
time. This is reasonable since rows almost always are
invalidated when a line is edited. Larger blocks
are typically less important.
This is experimental and might get reverted if proves
to harm more than help.
Change-Id: I6e4420e07a031805c1e2729b3f32de580ae4806e
Reviewed-on: https://gerrit.libreoffice.org/29289
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Delaying the splitting maximizes the chances
that we will deduplicate and combine them
in the queue optimally.
Change-Id: Ib721fe7596de7ad5d34159949fe75f16e861eb24
Reviewed-on: https://gerrit.libreoffice.org/29287
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Swapping the views makes the current front
go to some random location, which isn't fair.
Change-Id: I147aceb6bc5e5eb751a86d557d72ecdedb34af23
Reviewed-on: https://gerrit.libreoffice.org/29286
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Even the order of the views matters when the editing is happening.
Change-Id: Id0868a8198f9fa955512fccba57fa063eab46e8c
Reviewed-on: https://gerrit.libreoffice.org/29284
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
When putting tiles into the queue, do only the de-duplication,
reprioritization is better at the get() time - no need to keep shuffling
the priorities according to the cursor moves etc. all the time.
The tile combination then does the rest of the work for us :-)
Change-Id: I100c433dd3b24228d1ca8e4c89891635db1115c1
Reviewed-on: https://gerrit.libreoffice.org/29283
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Instead of 2 queues and 2 threads, merge those to one - which gives a perfect
ordering of the invalidations and rendering.
Change-Id: I229dfc08b43e6ce7e4f08ea8059d3298d9bf8f8a
Reviewed-on: https://gerrit.libreoffice.org/29282
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
- show invalidated rectangles with fading effect
- show last tilecombine message and cancelled tile count
- show received/requested tile updates
- fix popup handling
- custom popup style (transparent, big numbers)
- clean up
It confuses me that 'it' is a reference, while 'payload' is a value, so
even if payload is a const value that's never written, it's not OK to
change it to a reference, as the underlying memory is released by the
in-between erase() call.
Change-Id: I05ad0f64e3eeedf847b74a6fadff610fc7469aa1
aka: don't save invalidated tiles into cache
Tiles that are rendered when invalidation is recieved are outdated.
What we do is remember the last tile version when we get an invalidation.
This tile version, and any preceding it, is out of date and should not
get saved in the tile cache.
This fixes a race between rendering and invalidation, which happens
in the following scenario.
1. Tile requested for rendering.
2. User inputs key.
3. While tile is rendering, the tile is invalidated in Core
(the shared lock between rendering and processing input doesn't
include parsing tile request or preparing the payload back).
4. Once the tile rendering is done, but before it's encoded and sent back,
the invalidation is received on the callback.
5. Tile cache is cleared of that tile.
6. The outdated tile is received on its way to the client, saved in cache.
7. Client requests the tile anew upon getting the invalidation.
8. The tile is served from the cache, which is outdated, therefore
missing the last key input form the user.
The fix is in #3 to remember the version number of the tile being
rendered. Then in #6 we forward the tile to the client, but we
do not store it in cache. In #8 the tile request results in a new
rendering, since the cache will not have the tile. Only this last
rendering of the tile is saved in cache for future requests.
Change-Id: I0b0a3c2b917906c0d0c9046e3e6d3d4d354a7777
Reviewed-on: https://gerrit.libreoffice.org/29209
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
This code throws sometimes. Rather than investigating what makes
it actually throw, lets kill it because we don't want any
editlock functionality anyways now.
Change-Id: I8a484ba9e3a658ca739122bb6d2d0c92c4180ff5
