this post was submitted on 21 Jan 2025
2 points (100.0% liked)
Tesseract
72 readers
4 users here now
Tesseract: An Advanced Lemmy Client
The goal of Tesseract is to address as many things in Lemmy that annoy me as I can. I also trawl various "is there any way to [blank] in Lemmy?" posts to get feature ideas. Both of those lists are pretty extensive, so Tesseract has accumulated quite a few features.
Github: https://github.com/asimons04/Tesseract/
Hosted / Demo Instance: https://tesseract.dubvee.org/
Note that the hosted instance defaults to Lemmy World, but it is unlocked to be able to connect to any Lemmy server.
Announcements, support, and guidance for the Tesseract UI.
All instance rules apply here. Beyond that, just be civil and constructive.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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 :)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).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.
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?