This is not common code, it's used only in the Kit.
Rename TileQueue -> KitQueue as well as unhelpful member variable naming.
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Change-Id: If158597f99f302cbc27e8eab139972f57a2fc3bb
Removed all MOBILEAPP preprocessor conditionals from Util.hpp/.cpp
Added isMobileApp function to help remove further conditionals.
Signed-off-by: Jaume Pujantell <jaume.pujantell@collabora.com>
Change-Id: I038a4db47ec2a2c7bb10f5696df5571b13bd9a61
StateRecorder.hpp split from ChildSession.cpp
KitWebSocketHandler.[ch]pp split from Kit.cpp.
ThreadPool.hpp split from RenderTiles.hpp
Expose headers for KitSocketPoll and Document
at the same time.
Not clear we need the DocumentManagerInterface anymore.
Conditionally compile out Document::createSession for unittest
dependency breaking, and avoid Rlimit::handleSetrlimitCommand
likewise.
Make makePropertyValue a private method of Kit.cpp.
clang-format new files.
Change-Id: I47a1d6afe20165f156b477a931b94c916cff4b9d
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
This moves ClientRequestDispatcher and all
its direct exclusive dependencies to its
own file and adjusts formatting.
No functional changes were performed,
although namespaces were restored and
other minor changes were done for
consistency.
The resulting file is still rather large
at around 2000 lines, but that makes
COOLWSD.cpp smaller by about 30% now.
Change-Id: I59bcd997ad08702ce7029c6791095e75ad9b23b0
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Extract some functions from ForKit.cpp and COOLWSD.cpp to new files
so we can do a kit in process mode without using ifdef directives.
Signed-off-by: Jaume Pujantell <jaume.pujantell@collabora.com>
Change-Id: I7529f8f46a8026318244666b27d1ce72ed5ad4ca
ClientSession::handleTileInvalidation returns early with _tileWidthPixel
(etc) of 0 because _tileWidthPixel (etc) never get set
These are supposed to get set from 'clientzoom' which the javascript
side sends. clientzoom arrives, but the attempt is made to dispatch via
a thread and during startup there are enough messages dispatched via
threads to overwhelm wasm
bundle.js:56376 ================ handle_cool_message(): 'clientvisiblearea x=-3915 y=0 width=20640 height=7980 splitx=0 splity=0'
bundle.js:56377 Tried to spawn a new thread, but the thread pool is exhausted.
This might result in a deadlock unless some threads eventually exit or the code explicitly breaks out to the event loop.
If you want to increase the pool size, use setting `-sPTHREAD_POOL_SIZE=...`.
If you want to throw an explicit error instead of the risk of deadlocking in those cases, use setting `-sPTHREAD_POOL_SIZE_STRICT=2`.
bundle.js:56376 ================ handle_cool_message(): 'clientzoom tilepixelwidth=256 tilepixelheight=256 tiletwipwidth=1536 tiletwipheight=1536'
bundle.js:56377 Tried to spawn a new thread, but the thread pool is exhausted.
This might result in a deadlock unless some threads eventually exit or the code explicitly breaks out to the event loop.
If you want to increase the pool size, use setting `-sPTHREAD_POOL_SIZE=...`.
If you want to throw an explicit error instead of the risk of deadlocking in those cases, use setting `-sPTHREAD_POOL_SIZE_STRICT=2`.
bundle.js:56376 ================ handle_cool_message(): 'tilecombine...'
The 'clientzoom' never get processed and so
ClientSession::handleTileInvalidation returns early with _tileWidthPixel
(etc) of 0 because _tileWidthPixel (etc) never get set.
this std::thread dispatching of messages is similar to seen in
gtk/mobile.cpp in similar code, and also existed in
android/lib/src/main/cpp/androidapp.cpp before getting replaced
in:
commit 155718796e
Date: Fri Jul 19 16:43:44 2019 +0200
android: Fix a threading / ordering issue.
follow the same simpler android model here.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I3b5e57b3d91bb80fbae90b269300581825518d7f
This is in line with MOBILEAPP and GTKAPP and
is independent of __EMSCRIPTEN__.
Replace all application-specific cases, leaving
only toolchain-specific ones (such as include
protection).
Change-Id: Ic44288aa5ace51e0a8b54566170c19120f7bf0dd
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
the default suggestion uses --enable-qt5 which isn't needed for
LOKit and breaks finding custom notebookbar widgets so online
notebookbar doesn't work with it.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I644924a0f8cdb01d4ec20d70ff7aedb27a2c899f
with in in place the sizes are
-Os for core and online
du -h online.wasm 155M
-Oz for core and online
du -h online.wasm 145M
and a warning of:
em++: warning: running limited binaryen optimizations because DWARF info requested (or indirectly required) [-Wlimited-postlink-optimizations]
without gseparate-dwarf the sizes are:
-Os for core and online without -gseparate-dwarf
du -h online.wasm 133M
-Oz for core and online without -gseparate-dwarf
du -h online.wasm 119M
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I91586abe0e52f6de20d0f04636bb5a2be93d92be
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
otherwise generated:
| int
| main ()
| {
| return dlopen ();
wasm-ld: warning: function signature mismatch: dlopen
>>> defined as () -> i32 in /tmp/emscripten_temp_6nz4f0ww/conftest_0.o
>>> defined as (i32, i32) -> i32 in /home/builder/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/libc.a(dynlink.o)
em++: error: running limited binaryen optimizations because DWARF info requested (or indirectly required) [-Wlimited-postlink-optimizations] [-Werror]
and erroneously claims that dlopen is not present, and
configure fails.
Change-Id: Ie54db7c2099787a0b63b76b0b6e3e44750c9046e
Signed-off-by: Michael Meeks <michael.meeks@collabora.com>
Not sure why I now suddenly needed this, too, when I recompiled Poco
for WASM (with different options than before).
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I7221947e0cd2264535b6d34e0640b95d7cfc7cf4
We are logging what we are evaluating as JavaScript later in the
function anyway.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I79972ec585dee128bbcca910def1d46e8134cdc5
Newer Emscripten SDKs no longer provide <sys/epoll.h> and
<sys/inotify.h>. The corresponding functionality is not present, I
assume.
Until now we have been using Emscripten SDK 2.0.31 and that is still
the recommended known-to-work version, but I am experimenting with the
latest, 3.1.30.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I26e89dc38554548aee3ce2dbf6ba352917ba6266
LOKit will be initialised in the lok_init_2() call in lokit_main() in
Kit.cpp. This change also puts setting and getting the LOK_OPTIONS
environment variable in the right order.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Iee6f5adcb60bb887083c67666c2d597a15686bf9
Signed-off-by: Tor Lillqvist <tml@collabora.com>
You now must pass --with-wasm-additional-files=<path> where path
contains a file called sample.docx.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I21e62feb6282833a5d60b31db26328eda63cdaea
Now I hope things are initialised in the right order and the plumbing
gets set up so that messages are passed as expected. It seems to work
most of the time.
Main changes are:
- The online WASM executable is built using the -s MODULARIZE -s
EXPORT_NAME=createOnlineModule options. This means that the WASM
runtime is not automatically initialized and the main() function
is not automatically started. Only when the createOnlineModule()
function is called is that done. Calling exported C/C++ functions
is a little bit more complicated.
- Code to actually Base64-encode strings to be executed as
JavaScript when expected is now present in wasmapp.cpp. (After
being passed through the Base64ToArrayBuffer function on the JS
side.) Whether this is actually necessary is not fully clear, but
to keep the code similar to that in the GTK, iOS, and Android
apps, this is kept as such for now. It would probably work fine to
just directly create the ArrayBuffer in the C++ (using the EM_ASM
magic).
- The COOLWSD::run() function is now run in a separate thread so
that main() can return.
- The FakeWebSocket's onopen() function is now called from
innerMain(), where the HULLO message is sent. It remains a bit
unclear if this really is the ideal place.
In the mobile apps the HULLO message is sent and the onopen()
function is called in the window.socket.onopen() function in
global.js.
But note that despite that the WASM app and the mobile apps are
largely quite similarly constructed and the FakeSocket and
FakeWebSocket plumbing is the same, there is an important
difference. In a mobile app the C++ code is what runs first, and
that then loads the HTML page into WebKit, in which the JS
runs. In the WASM app it is the other way around. The web page is
naturaly the one that is loaded and the JS code then starts
running the C++ code as WASM.
Finally, note that the whole concept that there is a separate "WASM
app" is temporary.
What we eventually want to achieve is that the COOL webpage upon
loading will connect a COOL server. As it does currently. The COOL
server runs the online and core C++ code to load a document, and
renders document tiles and sends those to the client JS code to
dispay.
The new thing will be that, if enabled, in addition to the HTML and JS
resources, the client will also download the WASM code and data
resources. Also, the document and updates to it will be downloaded
while being edited so that a copy can be kept in client memory. But
the WASM code and the downloaded document will remain unused most of
the time. Only if the connection to the COOL server breaks will the JS
start running the WASM code and the JS will talk to online code
running locally as WASM instead of to a COOL server. Obviously there
are still lots of things hanging in the air here regarding how exactly
this will work.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Ib1786a0b485d51797b0f2302d4296aa1ff9df5c1
After my shortly upcoming commits the document gets loaded and its
tiles displayed by the code that normally does that. No need to
separately verify that loading a document works.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Id5883f36644b5e9b79c3f80ea2131e9f35823b2f
Apparently handle_cool_message() gets called from a web worker thread
and then using emscripten_run_script() in wasmapp.cpp to run a JS
snippet that refers to the 'window' variable will not work. That
variable exists only in the main thread. So use MAIN_THREAD_EM_ASM()
instead.
Hardcode the document URL for now also in wasmapp.cpp.
Try to send the HULLO message from COOLWSD::innerMain().
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Ic48042c6d0c6239a3b82e74f0565056a15f3d98d
As we build a single statically linked bunary for WASM, we will end up
with just one copy of each function in it. Both LO core and Poco
include expat. Upstream Poco builds one of the expat source files as
C++. That causes trouble as it then isn't compatible with what LO core
wants to call. Or something like that. You get "RuntimeError: null
function or function signature mismatch". (The "signature" concept in
WASM is orthogonal to C++ name mangling.)
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Iacf75ed34eea98611cb6aa6867e460697ea1fc4a
This revealed some interestring problems related to expat, static
linking, and how expat was built in Poco.
Don't bother saving the document, though.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I6715beb46ad6c4854ffc8aff6a26419c05727ae7
No need to start a separate thread to run it, like in the gtk+
"mobile" app, I think.
Also no need for a cleanup function, I think.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I23e94200047a195b7fecbdf370142daebc3df55c
We want the code to go further and not stop right away.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Id285f119dde0894cda59b68ebd02a9f6b0e2fbee
Just 4 is very likely not nearly enough. I think I did see some error
that could be related to running out of threads. Does
PTHREAD_POOL_SIZE limit how many threads can exist simultaneously?
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I5da637b5660e89655f7049b6754f70c74dff6da2
Also using soffice.data name instead online.data: online.js
looking for soffice.data
Signed-off-by: Balázs Varga (allotropia) <balazs.varga.extern@allotropia.de>
Change-Id: I62cee3f4866a2824a08b472f15bcdec06a6407b9
* add dependency on soffice.html.linkdeps to rebuild if core was rebuilt
* copy needed data files as-is from core build
* rename executable by setting automake EXEEXT var - appears to work
Signed-off-by: Michael Stahl <michael.stahl@allotropia.de>
Change-Id: I458b49290dae9d621a8043b1b3103d8b8fd606b8
The LO build directory in question needs to be one separately
configured for this (not one that would use Qt5 for UI, for instance),
so in the long run perhaps it does not make sense to create the FS
image there in core, but we should do it here in online? And we will
surely need additional files in the fs image anyway that core knows
nothing about.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I2cff0421da6075eefc017603ddf9d2ecf9dc79e2
It is called from JavaScript with one parameter, the string containing
the message to be sent to the Online C++ code. (See
browser/html/cool.html.m4.) It is not called from the mobile app glue
code.
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: I893dfff3b7d2dbfe4bd48393e58a8c6bfc6e2931
Michael Meeks
Aron Budea
Jaume Pujantell
Ashod Nakashian
Caolán McNamara
Balázs Varga (allotropia)
Tor Lillqvist
Michael Stahl