Some times tiles with the same wireID survives the wireID
filtering in kit, so we should do that in wsd too.
The issue is with the tilesBeingRendered construction. First when
one tile is filtered out on kit side the client remains subcribed
to the tile, since wsd does not know filtering happened.
Second via the tilesBeingRendered object more clients can be subcribed
to the same tile and so when one client request a new version of this
tile (with an old wireID) the rendered tile is sent to all subscribed
clients even if the other clients has up-to-date tiles.
Change-Id: I4ca6b7a83a5d6979a9f924d766a71aba5e5362c7
Since this commit:
9473908d45
We can avoid that, because the tiles will be invalidated
on the client side and when the client visible area changes
the invalidated tiles are requested anyway.
Change-Id: I272e3b4b87380ae574c16a2b480dbc8caabf4b32
I changed the code in this commit:
c2a5f6acb0
To make kit send a tilecombine message even if it does not
send actual tile data so we can track that the rendering was
done and so we can update the clients' _tilesBeingRendered
list. The issue is that tileBeingRendered object
belongs to not only one client, but more and so we don't
know which client gets the actual empty tile response.
So revert this method and rather use a smaller timeout for "waiting" the
arrival of the rendered tile.
Change-Id: I2dbbab1a62b81cbbb5314f2f37fdbc3415c69130
When we're doing the prerendering we also need to register
a tileBeingRendered object, so we know that the given tile
will arrive soon. In earlier version of the code, rendering
and sending of the tile was not separated in time, but now it is,
so we need create a tileBeingRendered object even if we don't
subscribe the client to it yet.
Change-Id: I1374c22e5ffebe1d6fcc6e37261ddcedeb9066ec
This invalidCount does not work perfectly, since we don't always
send tile after every invalidation message (e.g. tile deduplication
on severs side, wireID handling). So this invalidCount usage should
be reconsidered. Now just avoid to have a tile still invalid after
we requested (and get) the newest tile when we are changing the view.
Change-Id: I249be63611767af02b04e142bb1c2afcb3a8eebb
The main purpose of this time-out is to avoid waiting forever for lost
tile messages, but since it rare to loose them we can use bigger value,
so we can avoid to send new tiles to a slow network.
Note that the used time stamp does not mean the time when the tile
actually send to the client, but the time when it gets to the sender
queue.
Change-Id: I230d85c38b3a5dafd195851d0cf4caac23149e3e
There valid cases when we get unknown tileID. For example we
sent some tiles, but in the meantime canceltiles arrives which
resets tiles-on-fly list, but the client still send tileprocessed
messages for earlier requested tiles.
Change-Id: If2ec015106a0e58d66ae4517b64a9552eb8c38fc
In this case the part number is undefined, somewhere it is set to 0 or 1,
but has no meaning at all. Just avoid using it with text ducments.
Change-Id: Ic98217bf3ea6c86d37c34e42302bf456f7274975
This stuff is a bit fragile, and the presence of other apps on the
device that claim to support "our" file types might, or might not,
affect how it works. Also, upgrading to iOS 12 seemed to have an
effect. Anyway, now it is back to working as I need.
On iOS it shouldn't actually be pointer to a pixel char buffer, but a
craphics context reference. (This is how it has been since the
experimental TiledLibreOffice app, maybe five years ago? Sadly it
wasn't documented in the LibreOfficeKit include file. But it is how
LibreOfficeLight used the API, too.)
In TiledLibreOffice we rendered tiles directly into the CALayer of the
view. In this Online-based app we of course do render tiles into pixel
char buffers, just like in real Online, but we need to create bitmap
graphics contexts for them and pass that to paintTile().
Now I get white tiles, not totally zero-filled ones. But still no
document contents rendered.
I don't yet want to change the pBuffer parameter to actually be a
buffer pointer on iOS, too, like on other platforms. Also, changing it
will mean the LibreOfficeLight app would need changing, too, and I
don't feel like doing that. But ideally, sure, that should be done.
Re-think the plumbing between the different parts of the C++ Online
code. Do try to have it work more like in real Online on all but the
lowest socket level. Except that we don't have multiple processes, but
threads inside the same process. And instead of using actual system
sockets for WebSocket traffic between the threads, we use our own
FakeSocket things, with no WebSocket framing of messages.
Reduce the amount of #ifdef MOBILEAPP a bit also by compiling in the
UnitFoo things. Hardcode that so that no unit testing is ever
attempted, though. We don't try to dlopen any library.
Corresponding changes in the app Objective-C code. Plus fixes and
functionality improvements.
Now it gets so far that the JavaScript code thinks it has the document
tiles presented, and doesn't crash. But it hangs occasionally. And all
tiles show up blank.
Anyway, progress.
Change-Id: I769497c9a46ddb74984bc7af36d132b7b43895d4
No need for explicit "0x" and std::hex when outputting a pointer. A
pointer will be output as a hex number anyway. We used to have things
like this in the log:
TRC #25 Connected to WS Handler 0x0x3610b60| ./net/WebSocketHandler.hpp:80
At least LOOLWSD.cpp has a couple of global variables of types that in
their constructors invoke FakeSocket APIs. If we turn on FakeSocket
logging (fakeSocketSetLoggingCallback()) only in the app's
initialization code, we will miss logging from those global variable
constructors.
Sure, the clean solution would be to turn those global variables into
members in the LOOLWSD class instead, but this will do for now.
Not sure whether the shutdown() implementation matches real shutdown()
semantics, especially with regards to the behaviour of poll(), read(),
and write() (on both the socket itself and the connectd one)
afterwards. But let's see.
The feed() API turned out to be not needed. (And in any case, it was
suposed to be completely equivalent to writing to the peer socket.)
Won't actually be needed anyway, the way the code is going in my work
tree.
Change-Id: I4480ed59fe96ddcfad8483517f2a23452606f332
Reviewed-on: https://gerrit.libreoffice.org/60576
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>
It's easier to either call the function to set the logging callback,
or not, in one place in client code, than to comment in and out all
the logging lines in FakeSocket.cpp as needed.
Change-Id: Id17f7e461c7df817440b47cb3124fcece13b189b
As we use #ifdefs at all call sites anyway (because we don't dare use
the generic overrides of close() etc), we can leave out the parameters
related to actual BSD sockets that we ignore anyway.
"Real" Online always uses non-blocking sockets. We don't need to take
flags for that or check it. We can hardcode such behaviour always.
(Assuing that is what we want; let's see once something works.)
Change-Id: I6863907d71c5599b00ce1f8305a44d41bbaf7bee
That is how Online uses the sockets for communication between the
processes anyway: It send and receives complete WebSocket frames.
Sure, in the mobile case there is just one process, but (I think) we
want to keep the same basic structure anyway, even if "wsd" and "kit"
are just threads. (We probably also want to drop the WebSocket framing
of the messages.)
Change-Id: I2397f321029c1cbbbc448a9b2403ad185a51cf14
Intended as a replacement for the real sockets used for WebSocket IPC
in Online on Linux. The idea is that in a mobile app we don't want to
bother with any actual sockets or WebSocket protocol (because we are
running as a single process after all), but keep much of the code that
thinks it is using such mostly unmodified. Just an idea so far, let's
see how this turns out.
Change-Id: I7878b0db99d9cbf70650227186c1fec9677fa74b
Makes it easier to put a breakpoint in it in Xcode...
Not sure if we have any consistent convention around here anyway about
which member functions should be defined inline in the class
definition in the hpp file, and which ones should be in the cpp file.
