After processing a tile request for a slide preview, move the rest of them to
the end of the queue, so that other events are processed before we render the
next preview.
Change-Id: I82aa411406d6731b1c0bf3b849780220b5e68110
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().
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>
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>
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
A new queue with own thread now processes tile requests
so we have a chance to cull backlogged tile requests
that have since been invalidated.
This reduces load on the server significantly, especially
with multiple view at different zoom levels, and very fast
typing.
Change-Id: I6599939cd363dc71c30187f40d542aa37260dc56
Reviewed-on: https://gerrit.libreoffice.org/28607
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Introduce a bit of hierarchy there, at some stage we'll want to re-order the
tile requests a bit so that it works better for collaborative editing; for the
moment, removing the duplicate entries is enough.
