Otherwise if you edit a different part of the document and somebody else
selects a shape, you get an unexpected, annoying jump.
Change-Id: I161a27c8a69e0873de0ebe3a020e2868cbe0afca
It's too easy to forget the Log::end when using the Log::debug() etc
API. Not sure what could be done to that. Change the logging API to be
like LibreOffice's SAL_INFO?
This is fine since there is deduplication logic
in the queue before rendering, so it's safer
to pass client requests along and rather than not.
Change-Id: I6d50fc731a273d907e178827a09e8cf9a4b8345b
Reviewed-on: https://gerrit.libreoffice.org/29163
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Note that just like for loolwsd, LOOL_NO_LOGCOLOR is effective only
when stderr is not going to a terminal. If it goes to a terminal, there
is no way to avoid use of color, see Log::initialize().
... so that one can use the factored-out rule, build-l10n, to
install these translation .json files in dist/ and start using
them, without having to do 'make dist' first and then extract the
package.
Change-Id: Ie2814a9f2596246b487799968f3027aa48475e7b
The behavior has changed to include .pot files in git as well in
7839aecac6
So, don't try to delete these .pot files now
Change-Id: I6f5d015596ff1f2d98adca426b1458f66bc7d4b4
Reviewed-on: https://gerrit.libreoffice.org/29130
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Location was changed in 6c69b63be5
in an effort to modularize everything including these l10n
strings.
Change-Id: I4d7538a6e6d1370a45326bc163a496cf7c681259
This replaces addview/remview/remallview messages in the protocol
with 'viewinfo' message which is sent whenever there is any
change in the view information.
Let the client deal with what information is redundant to it.
Change-Id: Ic470ea88a94ff281a0ae021014a9fba1b876f648
And accept any version newer than expected.
Since we have proper de-duplication of tiles
requesting newer versions reduces changes of
races between client and the renderer.
Change-Id: I30bb53f98ef6f1461b53c1cf527d315dc35f7f26
Reviewed-on: https://gerrit.libreoffice.org/29125
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tile invalidation is a hint to the clients to request
fresh tiles and replace the existing ones. However
any outstanding tile request will be rendered anew.
So no need to remove those.
Nonetheless, we should issue new versions to avoid
race between old tile and invalidate. This can
happen when a tile rendered just before invalidate
reaches the client after the invalidate. The client
will think the tile is a new one when it was rendered
just before the invalidate.
Change-Id: Ieb2ffab1214dd904da8e532e7d9d20e6ad783b78
Reviewed-on: https://gerrit.libreoffice.org/29123
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
I wanted to try loolwsd built with _GLIBCXX_DEBUG defined and thus
needed cppunit built like that, too. (And Poco, but we already had
configury to point to a self-built Poco.)
On destroyView Core must flush the events queue, otherwise
by the next idle the descriptor will be gone and we'll
be using freed memory.
Change-Id: I6d3d8f9461bc156383a7294e9c65c535d79f2e7a
Reviewed-on: https://gerrit.libreoffice.org/29088
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Extending the document URL with debug=1 option will switch
- visible tile boundaries
- update numbers over tiles
and invalidated tiles will be blue during waiting for an update.
Seems to fix the deadlock problem, or at least makes it very much
rarer. (I am not entirely certain that a callback might not be in
progress already (in another thread) when we turn off callbacks, and
in that case the callback might still then access freed memory?)
It can return null for no obvious reason, leading to misleading
logging where the same thread is identified as numer zero at one place
and non-zero at another. So use the actual Linux thread id in logging.
Sure, thread ids are somewhat less convenient, as they are larger
numbers, from the same number space as process ids.
