While this has some overhead, it makes debugging of tile
rendering easier.
Change-Id: I0430015f41fd044e4be1099a5d61a23c0ef88176
Reviewed-on: https://gerrit.libreoffice.org/30245
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Document that the 'id' parameter of a 'tile' message is not (should
not be) used for anything except slide thumbnails.
If we later need some more generic way to distinguish the purpose of
tile requests, need to come up with something else, like a 'purpose'
parameter.
Instead of trying to inform the sysadmin (which we did not yet try to
do in any meaningful way), inform all connected clients (even those
editing other documents).
We use 'error: cmd=internal kind=diskfull' as the message to the
clients. The loleaflet code needs to be updated to handle that
carefully by displaying a very prominent message that tells the user
that all bets are off.
Also add a unit test for the functionality.
Document the new protocol details.
The code for this alert functionalty became a bit less elegant than I
like because of the way we include Util.cpp in the unit test 'test'
program.
Still need to add code to check for disk full in more places, not just
when saving a cached tile or font. Probably we should even actually
check for disk space on the file system(s) we use getting alarmingly
low, not just check for file writing operations that fail. Later.
The missing init of mutexes is probably theoretical, the TraceFile and
the Unit ones were real errors, I think.
Change-Id: If19c23a9c93d34059998346af8d45c26a34043a6
Introduce new API in our Util namespace to save data to a file
safely. The data is written to a temporary file in the same directory
and after that has succeeded, it is renamed atomicaly to the intended
name. If any step of the saving fails, neither the temporay file or
the intended target (if one exists before) is left behind.
Also add an API intended to alert the sysadmin in cases where their
attention and action are required. This is not yet properly
implemented. See FIXME comment for discussion.
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>
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>
Tile queue was used to process canceltiles commands.
Since those are handled by TileCache, there is no need
for queues and the threads that pump them.
But because these queues were also used to buffer between
WSD internals and clients, such that a slow client wouldn't
block WSD while sending back tiles, it is necessary
to reword that logic.
In subsequent commits that will change as well.
With this change not only do we save a thread per client,
but we also reduce latency of tile, and improve typing
responsiveness, by almost 3x or more! Latencies are
down to ~15ms from almost 50ms.
Reviewed-on: https://gerrit.libreoffice.org/28575
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
(cherry picked from commit 59eaacd2f8)
Change-Id: I77813267a95a724491165792ec020ae00953c05e
Reviewed-on: https://gerrit.libreoffice.org/29066
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tile queue was used to process canceltiles commands.
Since those are handled by TileCache, there is no need
for queues and the threads that pump them.
But because these queues were also used to buffer between
WSD internals and clients, such that a slow client wouldn't
block WSD while sending back tiles, it is necessary
to reword that logic.
In subsequent commits that will change as well.
With this change not only do we save a thread per client,
but we also reduce latency of tile, and improve typing
responsiveness, by almost 3x or more! Latencies are
down to ~15ms from almost 50ms.
Change-Id: I9bb5856efed28caea9d4e6f94f77b093779e5241
Reviewed-on: https://gerrit.libreoffice.org/28575
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Tile invalidation and painting can race with one another.
A race when the user types two characters in quick succession:
1. After the first key press, the tile is invalidated.
2. The client request the tile on receiving the invalidate.
3. TileCache doesn't find it, and adds subscription.
A. Sometime before rendering, the second key press is received.
B. This invalidates the very same tile.
C. The client request the same tile.
D. TileCache finds a subscription and ignores the new one.
4. The tile is rendered and sent back.
5. Subscription is found and the tile is forwarded to clients.
6. Subcription is removed as the request is fullfilled.
E. The second tile is rendered and sent back.
F. TileCache finds no subscription and the tile is dropped.
End result: Only the first character appears on the screen.
Versioning fixes the above situation by making sure that in
step 5 the subscription will show to belong to a different
(and newer version) and so the tile will be ignored.
Instead, at F the TileCache will find both subscription
and a matching version and the lastest version will always
be sent back to the client.
Change-Id: I7d7fe1407cda1908d794683c3ce4c2fd18609a2f
Reviewed-on: https://gerrit.libreoffice.org/25341
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
A source file (.cpp) must include its own header first.
This insures that the header is self-contained and
doesn't depend on arbitrary (and accidental) includes
before it to compile.
Furthermore, system headers should go next, followed by
C then C++ headers, then libraries (Poco, etc) and, finally,
project headers come last.
This makes sure that headers and included in the same dependency
order to avoid side-effects. For example, Poco should never rely on
anything from our project in the same way that a C header should
never rely on anything in C++, Poco, or project headers.
Also, includes ought to be sorted where possible, to improve
readability and avoid accidental duplicates (of which there
were a few).
Change-Id: I62cc1343e4a091d69195e37ed659dba20cfcb1ef
Reviewed-on: https://gerrit.libreoffice.org/25262
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
Obviously this is dangerous, since the id is not part of the
subscription key (the filename) so different clients could
have different ids on the same part, but in practice I
expect this not to happen. Though that clearly depends on
how clients use the id.
Change-Id: I52a0b043c9b5e5ad1111b692e4216cc9ffec5b2b
Reviewed-on: https://gerrit.libreoffice.org/24680
Reviewed-by: Ashod Nakashian <ashnakash@gmail.com>
Tested-by: Ashod Nakashian <ashnakash@gmail.com>
