!UbCmIlGTHNIgIRZcpt:nheko.im

nheko

551 Members
0.9.1 is out now! https://github.com/Nheko-Reborn/nheko/releases/tag/v0.9.1 Discussion about nheko, the desktop client for Matrix :  https://github.com/Nheko-Reborn/nheko Latest Nightlies: https://matrix-static.neko.dev/room/!TshDrgpBNBDmfDeEGN:neko.dev/192 Servers

Load older messages


SenderMessageTime
21 Jan 2022
@deepbluev7:neko.devNico|dev:D20:53:52
@im:itglob.ruim joined the room.23:07:19
22 Jan 2022
@bard:halogen.citybardwhy does nheko scroll down WAY faster/more than scrolling up?01:03:55
@bard:halogen.citybardimages may be related. usually it's like I've scrolled up a bit, then I want to look at something again, but going down makes me end up past it01:04:20
@deepbluev7:neko.devNico|dev
In reply to @bard:halogen.city
why does nheko scroll down WAY faster/more than scrolling up?
Yes
01:06:07
@deepbluev7:neko.devNico|devBecause of how the async delegate rendering works01:06:20
@bard:halogen.citybardso it can't/won't be fixed then?01:07:27
@bard:halogen.citybardif I could flick directly between images like element's media file view it might be a decent workaround01:08:23
@bard:halogen.citybardlike open the viewer for a pic and then hit up to go to an older one01:08:38
@deepbluev7:neko.devNico|devIt should improve with Qt601:09:53
@bard:halogen.citybardokay, cool. thanks for the info01:10:46
@red_sky:nheko.im red_sky|dev (nheko.im)Also, scrolling down usually implies scrolling passed things that are already cached01:16:57
@red_sky:nheko.im red_sky|dev (nheko.im)Scrolling up can be new things that need to be downloaded or fetched01:17:12
@deepbluev7:neko.devNico|dev
In reply to @red_sky:nheko.im
Also, scrolling down usually implies scrolling passed things that are already cached
The problem is rather that the scroll position is anchored at the top. That gets recalculated properly when the delegate heights get added there, but if you remove a large delegate, the height eastimate shrinks which speeds up the scroll speed all of a sudden or so. It's a bit weird :D
01:18:25
@deepbluev7:neko.devNico|devIf you render the timeline upside down, it behaves the opposite01:19:25
@red_sky:nheko.im red_sky|dev (nheko.im)
In reply to @deepbluev7:neko.dev
The problem is rather that the scroll position is anchored at the top. That gets recalculated properly when the delegate heights get added there, but if you remove a large delegate, the height eastimate shrinks which speeds up the scroll speed all of a sudden or so. It's a bit weird :D
But also, downloading blurhashes and such is more likely when scrolling up than scrolling down
01:20:10
@red_sky:nheko.im red_sky|dev (nheko.im)Those make scrolling slower01:20:15
@deepbluev7:neko.devNico|devblurhashes don't get downloaded, they get rendered!01:20:32
@deepbluev7:neko.devNico|devAnd while it makes the scrolling hickup, the size calculation is instant01:20:50
@deepbluev7:neko.devNico|devBecause we know the size before rendering the blurhash01:21:00
@red_sky:nheko.im red_sky|dev (nheko.im)But they take processing, which causes scrolling lag01:21:34
@deepbluev7:neko.devNico|devI'm not sure if rendered blurhashes get cached01:21:42
@red_sky:nheko.im red_sky|dev (nheko.im)
In reply to @deepbluev7:neko.dev
I'm not sure if rendered blurhashes get cached
I think the underlying images do, maybe not the blurhashes themselves
01:22:01
@deepbluev7:neko.devNico|dev
In reply to @red_sky:nheko.im
But they take processing, which causes scrolling lag
Yeah, but the hickups happen even if you have scrolled long past what is cached in both directions :3
01:22:04
@red_sky:nheko.im red_sky|dev (nheko.im)All I’m saying is, when you’re scrolling up, you have to download stuff that isn’t cached and that is a little slower than scrolling stuff that is cached01:22:42
@red_sky:nheko.im red_sky|dev (nheko.im)Which is usually the case when one goes down…01:22:50
@deepbluev7:neko.devNico|devYeah, but that makes scrolling stop, while the reason for scrolling down being unnaturally fast is something else01:23:22
@confusingmuffin:anontier.nlconfusingmuffin™ joined the room.07:13:11
@confusingmuffin:anontier.nlconfusingmuffin™ left the room.07:13:53
@jamm:geophystech.ruAndrey Stepnov joined the room.09:46:09

There are no newer messages yet.


Back to Room List