Conversation
|
I think for this to make sense we have to rethink how scroll position is handled - the PR does not restore my correct scroll position if I scroll up and exit/re-enter conversation - also not sure how we can show correct vertical scrollbar position on desktop - is there a performance issue this solves? I thought everything was cached on disk? loading 10.000s of items into memory might be an issue on some devices, but the UI is only rendering a small subset no matter how many items are in the backing list. For restoring scroll position to work we would probably need to translate scroll index to a message id - then load messages on initial load based on this message id plus enough items before/after to ensure we can show it the same place in list with the stored offset - complicating issue is a scroll index position can be system message or date header item. |
|
It sometimes takes a noticable time loading 1000 items (10MB).
More importantly, you cannot scroll up beyond 1000. You're stuck with just
the latest 1000 messages.
Loading 10,000 in one go is not feasible.
So we need to do this.
Homebase.ID https://michael.seifert.page
…On Fri, Mar 27, 2026, 15:55 Anders Carlsen ***@***.***> wrote:
*acarlsen* left a comment (homebase-id/chat-kmp#168)
<#168?email_source=notifications&email_token=AOOOMXXFK5C4Y5DJFFVANDT4S2I7BA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUGMZDAMRTGU22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4143202355>
I think for this to make sense we have to rethink how scroll position is
handled - the PR does not restore my correct scroll position if I scroll up
and exit/re-enter conversation - also not sure how we can show correct
vertical scrollbar position on desktop - is there a performance issue this
solves? I thought everything was cached on disk? loading 10.000s of items
into memory might be an issue on some devices, but the UI is only rendering
a small subset no matter how many items are in the backing list.
For restoring scroll position to work we would probably need to translate
scroll index to a message id - then load messages on initial load based on
this message id plus enough items before/after to ensure we can show it the
same place in list with the stored offset - complicating issue is a scroll
index position can be system message or date header item.
—
Reply to this email directly, view it on GitHub
<#168?email_source=notifications&email_token=AOOOMXXFK5C4Y5DJFFVANDT4S2I7BA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJUGMZDAMRTGU22M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2LK4DSL5RW63LNMVXHIX3POBSW4X3DNRUWG2Y#issuecomment-4143202355>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOOOMXQCVTLKRVFYVKFKXBD4S2I7BAVCNFSM6AAAAACXBMLTS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNBTGIYDEMZVGU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Could we limit load to 500 or something, then if user scroll up to top, we have an actual button like "Load older messages', then load next (older) 500 and so on - then only support saving scroll position in newest 1000. This is to to keep it simple.. the liststate and scrollposition is a pain to maintain/restore when loading new items even more so when loading items in batches. Alternatively we need to be able to initiate load of message from last scrolled item somehow, like cursor=messageId - and support paging not only when you scroll up to newer but also if you scroll down and you have remaining new messages to load (because you scrolled to middle of conversation). Still I am not sure we can achieve pixel perfect scroll position. |
Changes to load a small batch of messages up front and larger batches hereafter