When scrolling through the feed it randomly happens to skip a bunch of entries. It suddenly jumps far down the feed for no apparent reason.

Some observations and possible cause thoughts:

  • I believe it skips one load batch (20) of entries.
  • Scrolling up those entries gets me back to where I was in the feed.
  • I think it happens when the last entry of a previous load batch expands an attached media item.
  • It’s more apparent in media heavy feeds.
  • It’s independent of the scroll speed.
  • Lucki@feddit.orgOPEnglish
    1·
    6 days ago

    I tried a few times but couldn’t replicate the issue. I think I saw quite a bunch of times when it would have jumped but instead a different post quickly flashed for a fraction of a second but nothing else happened otherwise. I’ll keep running this alpha and report back if such a jump should ever happen to me again.

    However, I did notice from the continued rather fast scrolling, that now with the v1.4.30-pre-alpha-1 one core was constantly at 100% utilization - even when switching to this post and doing other things for a bit. Only a reload of the tesseract tab let the process get back to normal CPU utilization. The process was pasta, the network component of podman I believe. Maybe there’s some cleanup or cancellation still missing? I don’t think I saw this extensive utilization over such a long time with the v1.4.29 version. Oh well, that’s what an alpha is for :)

    • Admiral Patrick@dubvee.orgMEnglish
      1·
      6 days ago

      Are you running it in podman on the same machine as you’re running the browser?

      Not that there’s an issue with that, just making sure I understand which aspect is causing a CPU spike (server side or client side). There are some server-side components, but they don’t do a lot of heavy lifting: mostly ancillary, on-demand lookups (e.g. when you click on a Loops video, it does a server-side fetch to get the video URL since that’s not available otherwise in the metadata).

      I have noticed that older FF versions (I run ESR 128.5 on my dev machine) does have that issue, but newer, non-ESR on my main machine does not. I don’t recall when I first noticed that, but I think it was when I updated @sveltejs/adapter-node. I may try rolling that back to an older release (any newer, and it only works with Svelte 5 which I’m not ready to port to yet).

      • Lucki@feddit.orgOPEnglish
        2·
        6 days ago

        Are you running it in podman on the same machine as you’re running the browser?

        Yes. They’re both on the same desktop.

        Firefox is the latest 134.0.2.

        I do have that local media caching activated so it might be that the browser was still requesting or fetching media in the background even though I wasn’t even in the feed anymore. I’ll keep an eye on this and see if it is an issue in normal use when I’m not trying to replicate a scroll issue.

        • Admiral Patrick@dubvee.orgMEnglish
          1·
          6 days ago

          Well, I don’t think it was Svelte(kit) or its dependencies. I rolled those back to the versions I had prior to 1.4.21, rebuilt, and performance on FF ESR 128 was still abysmal. The main feed worked okay, but once I opened a modal or got to a GIF animation, it was basically at like 5 FPS with one CPU fully maxed out.

          So I downloaded the latest 134, un-tarred it to /opt, and loaded Tesseract 1.4.30 (since reverted to the current dependency versions), and performance is fantastic (comparable to Chromium on the same machine and non-ESR Firefox on my main laptop).

          One thing I noticed about the ESR version on my dev machine was that it didn’t act like hardware acceleration was working (for any website/app) where it does seem to work in the latest version. Could that possibly be an issue for you?