| 21 Jan 2022 |
 Nico|dev | :D | 20:53:52 |
|  im joined the room. | 23:07:19 |
| 22 Jan 2022 |
 bard | why does nheko scroll down WAY faster/more than scrolling up? | 01:03:55 |
| bard | images 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 it | 01:04:20 |
| Nico|dev | In reply to @bard:halogen.city
why does nheko scroll down WAY faster/more than scrolling up? Yes | 01:06:07 |
| Nico|dev | Because of how the async delegate rendering works | 01:06:20 |
| bard | so it can't/won't be fixed then? | 01:07:27 |
| bard | if I could flick directly between images like element's media file view it might be a decent workaround | 01:08:23 |
| bard | like open the viewer for a pic and then hit up to go to an older one | 01:08:38 |
| Nico|dev | It should improve with Qt6 | 01:09:53 |
| bard | okay, cool. thanks for the info | 01:10:46 |
 red_sky|dev (nheko.im) | Also, scrolling down usually implies scrolling passed things that are already cached | 01:16:57 |
| red_sky|dev (nheko.im) | Scrolling up can be new things that need to be downloaded or fetched | 01:17:12 |
| Nico|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 |
| Nico|dev | If you render the timeline upside down, it behaves the opposite | 01:19:25 |
| 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|dev (nheko.im) | Those make scrolling slower | 01:20:15 |
| Nico|dev | blurhashes don't get downloaded, they get rendered! | 01:20:32 |
| Nico|dev | And while it makes the scrolling hickup, the size calculation is instant | 01:20:50 |
| Nico|dev | Because we know the size before rendering the blurhash | 01:21:00 |
| red_sky|dev (nheko.im) | But they take processing, which causes scrolling lag | 01:21:34 |
| Nico|dev | I'm not sure if rendered blurhashes get cached | 01:21:42 |
| 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 |
| Nico|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|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 cached | 01:22:42 |
| red_sky|dev (nheko.im) | Which is usually the case when one goes down… | 01:22:50 |
| Nico|dev | Yeah, but that makes scrolling stop, while the reason for scrolling down being unnaturally fast is something else | 01:23:22 |
|  confusingmuffin™ joined the room. | 07:13:11 |
| confusingmuffin™ left the room. | 07:13:53 |
|  Andrey Stepnov joined the room. | 09:46:09 |
