Inefficiencies in text_builder's sendRawText method about browsh HOT 5 CLOSED

It certainly is a guaranteed lag of 200ms :(

I haven't tried any of Browsh in Chrome yet, there's just too much Firefox-specific code.

The only clue I have to the cause of the bug is that's maybe to do with that fact that the webextension hides all text when it very first loads a page. Note that this.buildFormattedText(); itself contains;

this.graphics_builder.getScreenshotWithText();
this.graphics_builder.getScreenshotWithoutText();

So the flow of text rendering events is this; native page load renders text, webextension boots and hides all text, text parsing begins and a hack to show text is needed, then actual text parsing begins for real in this.buildFormattedText(); which then does the only ever essentially needed show then hide of text.

Bear in mind that defaulting to having the native browser page rendered without text means that rendering of graphics frames is dramatically improved, by a factor of around 10.

from browsh.

I have an idea that also has some major disadvantages as it is probably a waste of resources (RAM, CPU) in itself, however that doesn't keep me from proposing it.

Did you think about using two renderers, one always rendering with text and one always rendering without text (so only graphics)? Everything else being the same, meaning they get the same user input etc.

In that case any inefficiencies caused by the hiding/showing of text should be eliminated.

This seems like a hacky solution (if it works at all). Just some food for thought.

from browsh.

I think the timeout (and other variables like it) should be configurable.

Then I could play around with it and I might figure out if the rendering problems become less with a higher timeout (than 200ms).

from browsh.

Already ahead of you there. The graphics and text renderers are already completely separate, sending frames updates independently.

I just realised, you know that sendRawText() is only for the HTTP Server? So this 200ms delay doesn't apply to the TTY client.

from browsh.

I just realised, you know that sendRawText() is only for the HTTP Server? So this 200ms delay doesn't apply to the TTY client.

It makes sense now that I know it. :-)

from browsh.