danielweck
commented
19 hours ago We need to implement a width threshold (minimum value in CSS pixels) for the "spans" in the bottom navigation bar, and skip rendering HTML elements that are too small visually / for hit testing with the mouse cursor. This will introduce gaps in the sequence of pages (or spine items, same problem with EPUBs etc.), but this is an acceptable tradeoff. In fact, the current rendering model doesn't allow pointing at individual segments anyway, so this will be a net benefit in terms of performance, no usability loss.
...what I mean by "skipping" HTML segments is that assuming a minimum width of let's say 20 CSS pixels (for hit testing with the mouse cursor), the rendering algorithm creates the first segment in the ordered list and consumes all available 20px for itself, skipping / eating the horizontal space that would normally available to overlapping subsequent segments. Then, the next visually-displayed / rendered segment may be at index N or N+x depending on how short the calculated segment with was (for example, 5px calculated per segment means that the "previous" segment consumes the next 3 items in the spine item / page list). In concrete terms, clickable / hoverable segment "page 1" (or "chapter 1") may be followed by "page 5" which will undoubtedly confuse users ... which is why it would be worth signaling this phenomenon in the GUI, perhaps a different colour and some additional text hint?
Problem to solve: if I remember correctly there are pixel-based calculations to map mouse offset with spine item / page index, so we will need to careful refactor this to account for the skipped items in the underlying spine data structure.
with the intel x86 manual (5082) pages, the bottom bar is extremely laggy and cannot render all the pages span elements.
https://cdrdv2.intel.com/v1/dl/getContent/671200
related: https://github.com/edrlab/thorium-reader/issues/2670
original: https://github.com/edrlab/thorium-reader/issues/1340#issuecomment-2486431941