The document can be zoomed in an out. Each zoom level corresponds
to a 20% increase or decrease in tile dimmension (in twips).
Zooming doesn't work well yet. Tiles are removed and readded to
many times and it looks bad. Also the zooming center has to be fixed.
Handle the start of a child process when needed centrally, not in each command
handler.
Also, handle unrecognized commands always already in the parent
process. (Command syntax checks still done in child process, though.)
Tiles are now correctly displayed.
Layers that request tiles from a socket connection need to specify
the 'useSocket: true' option. This way layers that do not require an
internet connection can be added (like a grid, ruler, etc.).
I've also fixed some coding style problems suggested by lintjs
For now, each LOOL client has a separate child process (or none at all, if it
has accessed only information found in the cache). This will obviously have to
chnage to handle collaboration. Etc.
The parent process talks the same Websocket protocol with the child
processes. When there is a child process for a client, traffic from the client
is forwarded as such to the child process and vice versa.
My comment in 1b0230e4df was misleading, even if
doing this for Unix only, if we had done it as I was first thinking, we would
have needed to pass sockets between processes. But we won't, we will instead
keep all the connections to the clients in the same master process, and pass
on the WebSocketg protocol as such to child processes. That way the child
processes can go away when idle, or crash, without the connections
breaking. Or something.
the '_addTile' method now also handles tiles comming from a websocket.
Tiles are no longer added in one batch as they are added when received.
Added twip to pixel and pixel to twip convertor methods.
1 twip = 15 px
'onopen' and 'onmessage' events are handled
in src/layer/tile/TileLayer.js
Tile data is received as an ArrayBuffer which contains a string message
followed by a new line and then by the actual PNG data. The PNG data
is encoded in base-64 in order to be displayed.
Will be needed if we want loolwsd to run on Windows. Then we will have one
process receiving the connections from WebSocket clients and sending the
accepted connection sockets to child processes thatr might be already running,
either because they have been "pre-forked", or because of a collaboration
scenario where new clients join a session working on a document.
But initially we will write this as if for Unix only, so development of this
migratory socket stuff is paused for now. (And it isn't even clear whether the
API design so far is a good idea and elegantly implementable.)
Having a 'close' would mean being able to do a new 'open', too, which
introduces unneeded complexity, at least at this stage.
Just start a fresh WebSocket connection for each document.
