after jump to single line, infinite scroll goes too slow

[balmas]

from @monzug

go to Carmina, Catullus in chrome and FF on desktop, Safari on mobile. go to 11.5 passage (https://texts-test.alpheios.net/text/urn:cts:latinLit:phi0472.phi001.alpheios-text-lat1/passage/11.5?subreference=11.5) then scroll down. it will show one line at the time. if I select Poem 11 from the TOC and scroll down, it goes super fast (https://texts-test.alpheios.net/text/urn:cts:latinLit:phi0472.phi001.alpheios-text-lat1/passage/11) or by clicking on the arrow next to Poem 11 (https://texts-test.alpheios.net/text/urn:cts:latinLit:phi0472.phi001.alpheios-text-lat1/passage/10.1-10.30) I thought it has something to do with the subreference navigation that could slow down the scrolling but in https://texts-test.alpheios.net/text/urn:cts:latinLit:phi0472.phi001.alpheios-text-lat1/passage/12?subreference=12 it goes super fast. is there anything that can be done to improve the scrolling?

response from @balmas

the problem here is that when we retrieve just one line, it overrides the default chunking which is by 30 lines, and then for the scrolling it retrieves line by line rather than by chunks.

[balmas]

the nemo application precalculates the chunks of passages which are retrieved together based upon the citation scheme of the text and the logic we apply to that in the scheme_grouper plugin method.

And when we calculate the next and previous ranges for navigation, we look for the current range in the precalculated list and then get next and previous from there.

this works fine when we only navigate by the precalculated passage ranges but when we use the find passage feature, we jump out of those and to either a single reference or a range which doesn't match any of the precalculated ranges.

The application was just defaulting to the immediate siblings if it couldn't find a match, but this made the scrolling perform really poorly on texts which are cited by line, because each line ends up getting retrieved individually.

Recalculating the passage ranges on the fly would be too resource intensive, given the large number of possibilities, so this fix tries to find which precalculated range the the jumped-to passage or range is in, and then complete that range as the immediate next/previous sibling to eventually get back on track with the original ranges.

It can't succeed 100% of the time, because it's not guaranteed that the passages can be numerically compared (e.g. in Ovid Amores, there is a poem identifed as "ep" rather than a poem number. In that case, I just give up and resort back to the single reference retrieval.

It's also tricky because in a multi-level citaiton, you can't compare the whole thing as a number, because, for example, in a numeric comparison 1.6 is larger than 1.61 but as a passage reference, 1.61 is after 1.6.

And then we could be comparing 2 different levels -- i.e. the user might jump to 1.2 where the default navigation is one more level down, e.g. 1.2.1

[balmas]

ok, this is hopefully fixed now. The fix won't apply to passage identifiers which are not numeric, but it should hopefully work for all other scenarios.

the fix applies the following logic:

if the current passage range is exactly one of the pre-calculated ranges, then next and previous are the precalculated next and previous, and everything is as normal, the scrolling just pulls the next precaculated range.

else if the current passage range starts at the beginning of a pre-calculated range, then the previous chunk is the previous pre-calculated chunk, and the next chunk is the next sibling of the end of the current range through the end of the the pre-calculated chunk of which it is a part.

else if the current passage range ends at the beginning of a pre-calculated range, then the previous chunk is the start of that pre-calculated chunk up to the previous sibling of the current start, and the next chunk is the next pre-calculated chunk

else if the current passage is in the middle of a pre-calculated range, then previous is the previous chunk is the start of that pre-calculated chunk up to the previous sibling of the current start and the next is the next sibling of the end of the current range through the end of the the pre-calculated chunk of which it is a part.

It might be easier to illustrate this by example though :-)

Homer is chunked by 30 lines

1.1-1.30 1.31-1.60 and so forth

The end of book 1 is 1.611

so if you jump to passage 1.15 the previous button will bring you to 1.1-14 the next button will bring you 1.16-1.30 and scrolling will bring in 1.16-1.30, and then 1.31-1.60 and so forth as normal

so if you jump to passage 1.611 the previous button will bring you to 1.601-1.610 (because it wasn't a full 30 line chunk anyway) the next button will bring you 2.1-2.30 and scrolling will bring in 2.1-2.30 etc as normal

if you jump to passage 2.1 the previous button will bring you to 1.601-1.611 the next button will bring you 2.2-2.30 and scrolling will bring in 2.2-2.30, and then 2.31-2.60 etc as normal

This should also work with ranges so so if you jump to passage 1.15-1.17 the previous button will bring you to 1.1-14 the next button will bring you 1.18-1.30 and scrolling will bring in 1.18-1.30, and then 1.31-1.60 and so forth as normal

And it should also hopefully work when the passage you jump to isn't the same level as the normal chunking, e.g. jumping to a poem level when the normal level is by line (1.2 vs 1.21 in Ovid Amores)

[monzug]

this is my favorite fix for the release. need to test all the possible scenarios but so far so good. Thanks!

[monzug]

tested in several greek and latin authors. it works as described except when the range is between two books, then it will count the 30 lines on the following book plus the few lines in the previous one. e.g. homer go to 1.440 - the range will be 1.440 to 2.30 see screenshot

@balmas, all works fine for me. just a small difference with your explanation.