Hm, this is cool but I’m not seeing the speed. I loaded this on my phone and did one scroll flick with my thumb. Immediately saw white screen and took multiple seconds to render the items.
iOS iPhone 15 pro.
I’ve run into this same problem before using tanstack virtual table and it’s usually do to a few things:
- Too much on band calculation blocking the renderer when the new items come into view.
- Not enough preloading of the items off screen
- Incorrectly calculating the virtual scroll height which causes inefficient re drawing during render.
Not sure what stack you’re running but it seems the table could use some optimization.
_bittere 32 days ago [-]
You're right, those are some trade-offs I've had to make. Not using Tanstack Virtual Table though, wrote a custom implementation with some help from our friend ChatGPT. I'll look into making it render faster!
Etheryte 32 days ago [-]
Out of curiosity, why SHA-256? I would wager using a non-cryptographic hash would be faster, no? In this context you don't need any of the crypto properties of it, so that could be an easy performance improvement for your cache.
It seems currently the scroll struggles when you jump around, e.g. when you click to the bottom of the scroll bar area, the scroll will jump twice, first as you click and the second time as it renders. This is not a big issue if you continuously scroll, but is very noticeable if you use page down or click on the scroll bar. At least on my system, there is a noticeable delay between scrolling and the items being rendered on screen, that might be a related issue?
Those notes aside, I could definitely see value for this in cases when you want to get a glance overview or similar of a large number of notes, it's a cool idea.
_bittere 32 days ago [-]
No specific reason: it's a great hashing algorithm, and the first that came to mind. I'll look into other hash functions. Thanks for the suggestion!
Yes, I believe the two are related (and related to the scroll event handler). I'll look into that too!
cmgriffing 31 days ago [-]
FNV-1a might be worth looking into. It's pretty fast
Is it fast by default? Every time I scroll up and down I'm looking at empty space while the notes load in. And it's not just initial network delay, even if I scroll over already loaded notes it takes time to display them.
I think it would be a lot faster to do this with native HTML.
_bittere 32 days ago [-]
Native HTML? As in actually rendering the 1M divs into the DOM?
32 days ago [-]
billconan 32 days ago [-]
how do you cache heights without rendering? It seems to be a chicken-egg problem, you need to know the heights to test visibility, but without rendering, you can’t know the heights? Or heights are obtained by invisible rendering in a hidden div?
_bittere 32 days ago [-]
What Seen does is render notes off-screen first, then pack them up in the container. So yes, it does use a hidden div in a way. Some CSS styling does not let you measure the height, which is why Seen uses an off-screen div.
billconan 32 days ago [-]
Thank you for the tips. the off-screen div can't set display to none right? otherwise the browser will skip rendering?
32 days ago [-]
bloomingkales 32 days ago [-]
Working with fixed heights makes virtualized lists more predictable, easier to implement.
_bittere 32 days ago [-]
While that is true, it's not guaranteed that all notes will be of the same height. Some notes might have more content, some might have less; which is why we need all the fancy JavaScript rendering.
32 days ago [-]
32 days ago [-]
Kuinox 32 days ago [-]
I have a 1k€ PC and this takes half a second to display anything when i scroll.
_bittere 32 days ago [-]
You're right
The speed is a major issue for everybody. I'll try my best to improve it.
Thanks for checking Seen out btw!
Yeah, sure! So there's a few ways you can think about it.
In a more general case where you can make no assumptions about what you're rendering, you first render whatever is on-screen (so that you can also calculate their heights and position other elements properly). Then you render everything else off-screen, measure the total height and set that as the height for your container (for your virtual list).
Then you could implement some sort of caching for the heights to reduce recalculation for future loads.
If you can make some assumptions, there are a lot of clever ways you could even skip the rendering-then-checking-height method completely. One example I can think of is for is images; the height of an image is already present in the metadata. You just have to multiply it with some scaling factor to make it fit in your UI. That's much faster compared to checking the height after rendering.
What Seen currently does is the first. But the next version is going to do the second: finding a way to set a note's aspect ratio constant across all configurations of screen sizes, so that you no longer have to wait for all that calculation to finish.
If I tap and hold the scrollbar on my iPhone and scroll around, I’m looking at a blank page the whole time because the virtual list is waiting for me to finish.
isoprophlex 32 days ago [-]
they're virtually all there, though! :^)
_bittere 32 days ago [-]
Oh yeah, that's a known bug. You're right, the scroll event handler is waiting for you to finish scrolling. I'm looking into it though!
helb 31 days ago [-]
I get zalgo-like glitches (overlaying notes) when resizing the viewport width in Firefox. Looks kinda cool though: https://i.vgy.me/JQsqZO.png
_bittere 30 days ago [-]
Oh boy... I'll have to look into why that's happening.
mousetree 31 days ago [-]
Cool name! (CTO of seen.com here)
G_o_D 32 days ago [-]
i have created one such in past, though not <1s but
one note - 167239 character long, total 662 notes takes 10s on initial load from server and rendering then its fast, CRUD operations doesnt lag, + filtering live search also fast enough fiktering 662 notes, only 2s
tobyhinloopen 32 days ago [-]
It is not even rendering 1,000,000 notes; just those visible on screen. The illusion breaks pretty quickly as soon as you scroll a bit. I feel like it could be much faster.
Since you can't CTRL+F them, they're not rendered.
Also... who wants to render 1M notes? Maybe if you can CTRL+F them...
_bittere 32 days ago [-]
Yup, that is true. And yes, it could really be much faster. This is an early preview though, and I'm working on it!
Also, Seen does have search. The problem with making it work with Ctrl+F would be to render all 1M notes (or at least some "shadow" version of them), which would really slow everything down. But again, maybe there is some other way - speed is one of the major concerns, and I'm working on it!
No offense but I feel like this is an overengineered solution that misses the problem. It may efficiently render millions of notes I will not take in my life but it is extremely ugly with the slow loading/populating the screen as you scroll. And scroll goes crazy if you try to drag and scroll.
I would prefer a note taking app that can render maybe 100 notes but doesn't have that scrolling behaviour.
_bittere 32 days ago [-]
Thanks for the feedback! Yes, that is true; the scrolling is a big issue right now. Working on it though. Thank you for checking out Seen!
- Too much on band calculation blocking the renderer when the new items come into view.
- Not enough preloading of the items off screen
- Incorrectly calculating the virtual scroll height which causes inefficient re drawing during render.
Not sure what stack you’re running but it seems the table could use some optimization.
It seems currently the scroll struggles when you jump around, e.g. when you click to the bottom of the scroll bar area, the scroll will jump twice, first as you click and the second time as it renders. This is not a big issue if you continuously scroll, but is very noticeable if you use page down or click on the scroll bar. At least on my system, there is a noticeable delay between scrolling and the items being rendered on screen, that might be a related issue?
Those notes aside, I could definitely see value for this in cases when you want to get a glance overview or similar of a large number of notes, it's a cool idea.
Yes, I believe the two are related (and related to the scroll event handler). I'll look into that too!
I think it would be a lot faster to do this with native HTML.
In a more general case where you can make no assumptions about what you're rendering, you first render whatever is on-screen (so that you can also calculate their heights and position other elements properly). Then you render everything else off-screen, measure the total height and set that as the height for your container (for your virtual list).
Then you could implement some sort of caching for the heights to reduce recalculation for future loads.
If you can make some assumptions, there are a lot of clever ways you could even skip the rendering-then-checking-height method completely. One example I can think of is for is images; the height of an image is already present in the metadata. You just have to multiply it with some scaling factor to make it fit in your UI. That's much faster compared to checking the height after rendering.
What Seen currently does is the first. But the next version is going to do the second: finding a way to set a note's aspect ratio constant across all configurations of screen sizes, so that you no longer have to wait for all that calculation to finish.
Since you can't CTRL+F them, they're not rendered.
Also... who wants to render 1M notes? Maybe if you can CTRL+F them...
Also, Seen does have search. The problem with making it work with Ctrl+F would be to render all 1M notes (or at least some "shadow" version of them), which would really slow everything down. But again, maybe there is some other way - speed is one of the major concerns, and I'm working on it!
I would prefer a note taking app that can render maybe 100 notes but doesn't have that scrolling behaviour.