Such a big commit to provide a fix which really only involves a few
lines in the graphics builder. It would seem that the very first time
the BlockCharMono font is rendered it needs a little delay. So there's a
refactor here to use a callback when requesting a screenshot with text.
All the other code in this commit is just the scaffolding to try to fix
this issue. It's all good stuff in itself. Basically stricter code
triggers for the different stages of page load: tab load, DOM ready,
page ready. I actually wonder if the TTY page loads feel snappier now?
closes#46
Input boxes are currently only one line and to not properly wrap. So
textareas are also one line. TBC...
Also includes:
* First implementation of the DOM MutationObserver. This needs to have
an eye kept on it in case some websites trigger too mutatation
events. For now it doesn't seem too bad. Although strangely it seems
to stop on Youtube after about 15 seconds.
Firstly, this improves performance on a larger pages. But it also
prevents browser crashes a very large pages by setting a limit to how
much work is done per frame.
Also includes:
* Thread safe cell map for simultaneously reading and writing to the
buffered frame of TTY cells.
* Improved webext tests so that they programmaticlly build DOM rects
based off simple text strings.
* CLI is now prepared for supporting multiple tabs.
* Refactored global vars into relevant files
* Now using real types in JSON sent to CLI
* Still doesn't fix integration tests
This offloads significant CPU load from the browser. However it's become
clear that the previous feature of parsing the entire DOM needs to have
an upper limit imposed. For instance large Wikipedia pages still cause
problematic CPU load.
This commit does not fix the broken UI so integration tests fail.
Instead of mirroring the browser's viewport, as if we had a camera over
the browser, the entire DOM is now sent in the frame. This means that
the CLI itself can scroll without having to wait for updates from the
webextension screenshotter.
The biggest refactor is separating out the DocumentBuilder from the DOM
Manager.
I also made consistent use of the mixin pattern I'd only half
implemented.
After moving to Tcell and implementing its screen diff updates, we can
no longer watch STDOUT to get frames during integration tests. Instead
we need to use Tcell's SimulationScreen and which has a GetContents()
method. This is actually also a much more robust way of being able to
see what Browsh actually outputs during testing.
This was primarily to get native diff'ed frame rendering.
Termbox-go doesn't support true colours, thus the switch to Tcell, but
as it turns out Tcell claims to have wider platform support, so it looks
like an especially good change.
So now the CLI will only try to update the terminal screen when cells
actually change. This has some significant performant gains, especially
when using Browsh over SSH.
Also note that this required a complete change of the frame data
structure sent over the websocket. Previously it was a little
structured, but now it is just a plain 1 dimensional array of pure
strings, even the RGB components are sent as integers in strings. If I
can find a way to unmarshal mixed arrays in Golang then it'll be worth
sending a mixed JSON array to save some compute overhead.
In the endless struggle to squash a Travis-specific bug, we now have
screenshots. Currently the screenshots are of the custom block font
state, so you can't read the text. But I'm planning on changing the
default state of the page to use a normal font - such that the
frame builder needs to toggle the block font on to build a frame. This
will make it more likely that screenshots will contain actual text.
Also removes the Mozilla Cliqz disclaimer tab on first startup.
Interestingly it has a carriage return in its HTML page title, which is
of course zero-width. But also the fact that this tab can sometimes load
before the requested tab at startup is a showstopper for automated
tests.
Using JS's `getComputedStyle()` for every character is too CPU
intensive, so instead I'm experimenting with using a custom font
to take the canvas snapshot. The font is made up of only the unicode
block character, which basically fills the entire space given to a
monospace glyph. This also means that we can fairly reliably work out
the visibility (whether it's obscured or hidden with CSS) of text.
This proves that frames can be generated on Firefox using the canvas and
a Tree Walker to examine text nodes. Already with little optimisation
frames don't ever take longer than 200ms to render.
Chrome has a MediaStream of the viewport, hopefully that will prove
performant as well.
This doesn't have functioning text colour detection or text occlusion
support. But early research suggests this will possible by comparing 2
screenshots: one with and the other without rendered text.
