Finally, an explanation for #GNOMESoftware's slow scrolling when browsing apps! Thanks to @kdwk for finding out that it only happens when the mouse is over the items instead of "in the margin on the side"…
The fact that it is hundreds of times slower, however, was a rather unexpected finding :blobsweats:
Wait a damn minute, look at that pull request discussion and the diff as committed… the CTO of #Firefox has amended #Mozilla's "Neutral" position regarding #JPEGXL to indicate that their "cost" concerns are mainly about the security risks of a decoder being 100k lines of C++, and that they would be "open to shipping" a memory-safe decoder that meets their requirements?
And some folks at Google are going to write that implementation in Rust?!
@taschenorakel Ah yes, just like how the Windows system crash screens are so detailed and helpful, with its bountiful logs and troubleshooting advice! That's *clearly* The Reason why it succeeded on the desktop™ :blobcatcoffee:
I find myself a bit surprised that banks, increasingly often, have random transient bugs preventing login with #Firefox (usually, if you try some hours/days later, it works), while logging in with #GNOMEWeb works fine during that time.
As a result, I'm increasingly starting to add banking websites as Epiphany "web apps", just-in-case. It also lets me pre-set the downloads folder to the correct folder.
I'm glad this exists as an alternative when needed.
@aral The fact is that it is using the very ancient VP8 codec (not VP9, not AV1, which are super CPU-intensive), because that's pretty much the only free codec you can do realtime encoding with "in software" on most computers.
Related to https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5908 there is work going on to make it use hardware-accelerated encoding when available, which I guess would open up VP9 and AV1 as possibilities, but I don't know if a codec change is in the plans.
@aral As a user, I remember the era between 2015 and 2020 where GNOME Shell's video screen recorder was *literally unusable* because the VP9 encoder could never keep up and would lock up your computer by filling up the RAM within a minute. I'm not making things up; this commit proves it: https://gitlab.gnome.org/GNOME/gnome-shell/-/commit/c61685e617
So, *very much* a technical limitation.
I would have appreciated if you had simply asked politely to begin with, & assumed good faith, rather than immediately publicly smearing #GNOME
I'm not a GNOME Shell developer, it was just my educated guess of the probable practical performance+legal tradeoff that occurred a decade ago.
Nobody closed nor opposed @YaLTeR's issue 3371 that you linked there, nor other issues AFAIK. It's just impossible without HW encoding for VP9/AV1, IMHO.
VP8 is the only usable "in software" Free codec out there. I know because (from experience) you typically can't encode VP9 realtime "in software".
@aral I am under the impression that the GNOME Shell screen recorder is optimized for variable framerate recording with minimum amount of information encoded, resulting in very small filesizes compared to other screen recorders. It is light on resources (I suspect it is much more efficient for encoding) and great for quick partial recordings to attach to bug reports (small filesizes), which is my primary usecase for it; it does not seem to be meant for files intended for editing in a NLE.
Since I've been jealous of my parents' JVC sound system, with its elegant brown wood #speakers and crisp sound with rich bass, I sent out my dad on a wild goose errand today to pick up an early-2000's JVC "mini-HiFi" compact stereo sound system.
Here it is stacked on top of their sound system while I was doing side-by-side comparisons. Their 3-drivers speakers still sound much better than these 2-drivers black ones… but mine was bought second-hand for 25 canadian pesos 😉
For the past 10+ years, I was unable to daily-drive the #Wayland version of #GNOME … …until version 45.2+, where performance improvements landed for my specific usecases.
Since then, for the past 6 months, I've been running 45.x on Wayland.
This week, when I went back to the Xorg/X11 version for 1-2 days, I was surprised to see it now feels unbearable to me *from a performance standpoint*! Even with animations disabled.
I guess I can't go back after having used a no-delays no-jank version 🤷
@debacle@SrEstegosaurio@andrew_shadura That it is "legal" does not make it the morally "right" thing to do, when you are not forking/renaming to a different app name to avoid tarnishing the upstream project's UX and brand.
This "packagers thinking they know better than the developers, and unilaterally patching things" mentality, along with distros often shipping outdated versions, is why many upstream software developers dislike dealing with Debian (& any LTS distro), and now ask users to test/run #Flatpak versions of their applications first and foremost.
@juliank@debacle@keepassxc It took me years to understand why Christian Hergert talked about "the right to request your app not to be packaged"… but after seeing xscreensaver being mispackaged against the dev's wish, multimedia apps getting butchered (missing codecs, etc.), WINE apps (such as Bottles) getting butchered, one of my own Python apps getting one of its dependencies swapped out for a friggin' Java library, I get it.
If you go against upstream's design, fork-rename the app.
#InvoiceNinja, a dedicated timesheets and invoicing web application, being somehow unable¹ to consistently support ISO 8601 for timesheets, gives me very strong #KRAZAM "Microservices vs ISO timestamps" satyre sketch² vibes.
I wish this was a joke on the part of the InvoiceNinja people, but apparently they can't figure out how to have their settings for YYYY-MM-DD dates & 24-hour times actually apply consistently for input in the UI 🤦♂️
Why does Mozilla #Firefox default to allowing websites to use persistent storage, and thus consume gigabytes of disk space when few websites actually have legitimate reasons to use the StorageManager? Isn't that both an invitation to fill my disk and a #tracking / #privacy pitfall?
Seems like there's no UI to facilitate selectively cleaning this stuff, i.e. nuking the local storage for all websites "except these few websites" (and without touching cookies), nor do I see a way to require opt-in.
@gnomelibre Bah non, je veux pas un navigateur complètement amnésique 😅 sinon je serais toujours en navigation privée...
L'idée serait juste que les sites devraient avoir à me demander la permission de faire du "Local Storage" (pas la même chose que les cookies), et qu'il faudrait un outil qui permet de purger le stockage local "autre que les cookies" pour tout sauf une "liste autorisée" de sites… présentement, la suppression est "tout ou rien".
Free & #OpenSource software contributor (#Linux + #GNOME + #GStreamer) since 2004. Currently co-maintaining the most magical desktop productivity apps combo you can find (@GettingThingsGNOME & GNOME Calendar), as their benevolent lean engineering manager + occasional User Interaction & UX designer.Waging war on mediocrity & unsustainability in business.Founder of @ideemarque + @atypica, and mercenary CMO @regento.Ex-Collabora, ex-psy, ex-Shinra.I don't roleplay but I wear a cloak. ❄️