Now i know why #Amethyst were slow and not really smooth at scrolling in low end phone,
This is intensive. REQ at every scroll movement is too brutal for relays and that also impacts client bandwidth usage (due to tcp nature, which also impact websocket. see: nostr:npub1nxtq2wx3knwl3slf5gu5sajl0x9legyjgnp70h7er0h0rnkv6kvs62hzq8 )
nostrudel in general makes my strfry give an error every time about REQs
Btw nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
Any plan to improve this?
I accept suggestions on how to download everything we need without new REQs. Usually we are severely limited by the maximum number of filters on a single subscription and have to split/merge into multiple calls on scroll.
But I don't think the slowdown is about the reqs on low end phones. It's about the lack of GPU power. We use the GPU a lot. And many phones have throuble clearing out the memory for textures fast enough on scroll.
And this is all without using the disk. I added our database for testing and then with the GPU + reqs + disk being used at the same time things get really hard. I need to see if I can build a single texture with most of the icons + low res profile pictures to minimize texture reloading on scroll
Lot of budget phones has weak GPU power for this. So need to do the other way to handle the scroll.
Try reserving 10 or 23 notes in memory to reduce the intensive operation.
We already reserve :) our cache is quite good for events. What you see on REQs is the app stopping to follow one card you stopped seeing and starting to follow another in the other way of the scroll.
You may need to improve stuff at status fetching, because i saw it was frequently REQ-ed during scroll
You need to. Every time you scroll, you see a new profile and the app must update the status of that profile. It rarely downloads anything but it must check to see if there was any update to the status.
Same for likes, boosts, reports, zaps, quotes, replies of both the note and the author of the message. We also watch for updates to the user metadata and relay lists of each author in the screen. If it is a replaceable event, then it gets from the replaceable and the normal reference.
If there is an inner event, like a quote or boost, then it does that for both events.
But don't you could fetch the update without CLOSE-ing and REQ again?
You could keep the REQ on actually
Not enough space generally. Many relays are still forcing max of 10 filters and 10 subscriptions. That's not enough for all the types of events we are constantly watching. So we have to constantly rotate to fit everything in.
The problem with this design are, simply sending CLOSE was not enough at certain conditions especially when user has slow network connection / has bad latency to some relays. It will still receive events even after sending CLOSE (well, TCP nature). So sending CLOSE after seconds of REQ will just cause another garbage traffic flood & wasting user bandwidth.
Oh yeah, on top of that many relays never actually close anything and keep sending stuff even for past filters. Many implementations kill the entire connection to get rid of old subs. Welcome to nostr :)
But like I said, the processing of reqs and returning events is quite fast, like 30 micro seconds or so. I don't think that is much of a slow down, even in feature phones.
The Compose UI itself is slower than processing.
The UI is slow. Yes.
But the network too X)
The relay side may already know that the client sended CLOSE and has stopped transmitting, But client is still receiving all of the packets. So still painful
I think you may need to keep the current values into cache database until user may reopen it again, Unless the focused stats was the current stat (the current post should receive live stats, the replies should not).
So it's basically like sending CTRL+C in SSH after you are doing a big `cat`.
How about only start REQ-ing these infos once the user stopped scrolling? I think that would be a good idea instead of doing it at every scroll movement.
Today it waits 300ms before requesting. We can wait more but the updates start to become noticeable and somewhat annoying like a 10 fps game, even though the screen is at 60 fps.
