DOM renderer: care package issue

[jerch]

Thanks to @willmcgugan I have some heavy load examples to test on the DOM renderer, in particular:

• the colortest file for here
• textual easing to spot render glitches and update behavior (install with pip install textual-dev)

Issues found so far:

• The PR Fix for #2488. Use element offsetHeight rather than getBoundingRect #4366 changed char measuring to the integer based value retrieved from offsetWidth. Already suspected this to introduce artifacts for the letter-spacing trick, where rounding offsets will stack up, and yes it does showing staggering at the right side (scale demo to 310x70 to see the colortest file at full glory):

  

  Not sure yet what the right solution to this is, at least getBoundingRect gets the values right not showing the staggering.

• getAttribute & setAttribute are very expensive in the colortest accounting for 50% of script runtime (~800 ms), we prolly should resort to collecting style entries in JS and setting it only once on the element.

• Overall render runtime is bad for the colortest, it takes ~3 s on my machine. Can be made faster by:

  • display: inline lowers render time to 2.3 s (measured, inline-block vs inline in DOM renderer #4632)
  • fixing setAttribute minus ~500 ms --> down to 1.8 s
  • selection bug better handleSelectionChanged in DOM renderer #4633 minus ~300 ms --> down to 1.5 s

  Still underwhelming, but at least ~2x faster (note that the webgl renderer takes only ~50 ms to paint colortest).

• As already mentioned by @mofux, block chars render poorly in the DOM renderer. textual uses those to color its surface, which results in ugly stripes. It is also the root cause for the staggering above, as colortest also uses different block chars. We should investigate, if we can draw block chars ourselves not relying on the font renderer.

• textual easing does some weird color trickery at the menu on the left side to give the illusion of raised button borders. While the canvas and the webgl renderer show these, the DOM renderer shows plain colors. Prolly related to our decoration/line-height in the DOM renderer.

[Tyriar]

We should investigate, if we can draw block chars ourselves not relying on the font renderer.

As in custom glyphs in the DOM renderer too? You could make an image out of the rendering as done in the texture and link to that image, or use an SVG? We could also add a canvas to do it but I think it's a good thing that the DOM renderer is entirely canvas free as weird corruption/driver problems can happen on the canvas renderer too

[jerch]

@Tyriar Yeah, would be good to keep the DOM renderer impl canvas free, it seems there too many machines out there with serious canvas issues. Which then raises the question, how we could possibly create such images on the fly (canvas would have been the natural choice here).
I am pretty sure that SVG could fill that hole. No clue yet tough, if it will pay off or bring more glitches/issues to the table.

[Tyriar]

I guess svg is the only way unless we want to include a codec which would be overkill. I don't really want to maintain svgs for these either though so I think I'd prefer to keep it out of scope for the dom renderer tbh.

[jerch]

Hmm would there be other options? SVG indeed sounds like a lot of trouble to deal with, while the result is uncertain.

Only other option I could think of is a custom font for block chars drawing closer to the edges (is that even possible? or would the font renderer always introduce ugly spacing?), and to be loaded before the main font (pretty much like font-awesome does). But ofc - it is an even bigger hassle to get there.

Since this is only about beautifying output glitches, I also dont see this as an important issue at all. Still if there is an easy way to fix it - I am all ears.