So, I can confirm that fixing (see PR #80 ) the performance issue related to the "blanket" application of background-color (sepia or night modes) on all elements in the document's body ... results in a "small" regression with borders / labelled outlines. I say "small", because in my tests the performance degradation was orders of magnitude more detrimental than the visually-annoying border outline (striked-through label).
Screenshots:
Of course, ideally we would find a solution to the performance issue that would not break publication documents ... but unfortunately I ran out of ideas (and time) so I settled for the workaround of applying a transparent background colour everywhere.
Also, note that my fix works in Chromium 80 (Electron 8) ... but your mileage may vary in other browser engines. I suggest using Children's Literature ( https://idpf.github.io/epub3-samples/30/samples.html#childrens-literature ) in order to test the performance impact of CSS design choices (including triggering the GPU 2D / 3D acceleration, in some cases, like I did in ReadiumCSS PR #80). That is because Children's Literature has a single relatively-large spine item in the reading order ( https://github.com/IDPF/epub3-samples/blob/master/30/childrens-literature/EPUB/s04.xhtml ), so when font-size is cranked-up between 150% or 200% for low-vision users, the CSS column pagination spans a great number of pixels on the horizontal axis (consequently, the browser engine's layout and rendering subsystem must then somehow optimize these textures in memory / on the graphics card, and it seems that some combination of CSS rules trigger a more performant render path)
Originally posted by @danielweck in #68 (comment)
So, I can confirm that fixing (see PR #80 ) the performance issue related to the "blanket" application of background-color (sepia or night modes) on all elements in the document's body ... results in a "small" regression with borders / labelled outlines. I say "small", because in my tests the performance degradation was orders of magnitude more detrimental than the visually-annoying border outline (striked-through label).
Screenshots:
Of course, ideally we would find a solution to the performance issue that would not break publication documents ... but unfortunately I ran out of ideas (and time) so I settled for the workaround of applying a transparent background colour everywhere.
Also, note that my fix works in Chromium 80 (Electron 8) ... but your mileage may vary in other browser engines. I suggest using Children's Literature ( https://idpf.github.io/epub3-samples/30/samples.html#childrens-literature ) in order to test the performance impact of CSS design choices (including triggering the GPU 2D / 3D acceleration, in some cases, like I did in ReadiumCSS PR #80). That is because Children's Literature has a single relatively-large spine item in the reading order ( https://github.com/IDPF/epub3-samples/blob/master/30/childrens-literature/EPUB/s04.xhtml ), so when font-size is cranked-up between 150% or 200% for low-vision users, the CSS column pagination spans a great number of pixels on the horizontal axis (consequently, the browser engine's layout and rendering subsystem must then somehow optimize these textures in memory / on the graphics card, and it seems that some combination of CSS rules trigger a more performant render path)
Originally posted by @danielweck in #68 (comment)