phosh 0.13.0 is out 🚀 :

Improved call handling when shell is locked, lockscreen notifications, high contrast theme support and much more. Check the release notes.

@agx Sounds great, thank you for your work! I'm using phosh on a Pinephone via Manjaro. I really like it so far, but a most obvious issue to me is that the UI (including scrolling) behaves very slowly. Is this due to the Pinephone hardware (and faster on the Librem) or do you see possibilities to apply further optimization/hardware accleration or similar?

@letterus @agx Most of apps you're likely to run under phosh (and also phosh itself) is still based on GTK3, and GTK3 is purely software rendered - PinePhone's slow memory bandwidth is a huge bottleneck there. It is noticeably snappier on the Librem 5 since its RAM is significantly faster.

One thing to check is whether arm64 optimizations are enabled in pixman build used by your distro, there is a patch that's not merged upstream that can make it a bit faster overall.

@dos @agx Thank you. Pure software rendering explains a lot of the behaviour I‘m seeing. 😉 So that would change with GTK4?

@letterus @agx Possibly. GTK4's GPU rendering isn't well optimized for mobile platforms, but it already got pretty usable in GTK 4.2. There will still be some work needed in order to keep slow GPU-rendered clients from making the whole compositor slow (like, so there's no single silver bullet, but we'll get there eventually ;)

@dos @agx Thank you for your explanation! Keep up the good work!


@letterus @agx One more thing: a possible feature that could be added to phoc to make platforms like PinePhone faster even with software rendering is to render everything in smaller resolution and then upscale while displaying. This will of course make everything blurry or pixelated, but should make it very snappy even with underpowered hardware.

@letterus @agx Some people may strongly prefer snappiness over sharpness, so why not give them a choice? :)

@letterus @dos @agx It would be a reasonable workaround for hardware that isn't well balanced (e.g. too high resolution for the available memory bandwidth) - similar to removing compositor-level eyecandy on weak devices.

In an ideal world, the entire software stack would be suitably optimized. Until then, workarounds can help people make the jump (in this case even with the promise that the workaround could be disabled down the road if software catches up).

@patrick @letterus @agx Such workaround would be opt-in anyway (unless a distro maintainer opts-in for you of course ;))

@dos @letterus @agx If that issue remains around for a while longer (e.g. because moving away from GTK3 takes a while) it might be worthwhile to consider making it a default on known-slow devices, maybe with a notification, to provide a better experience for first-time users.

I don't have studies at hand, but IIRC human eyesight is generally more tolerant to blur than to choppy motion, and there's only so much a user endures before rejecting a project as unfinished for a _long_ time.

@patrick @letterus @agx That would be something for system integrators/distro maintainers to decide and apply though, no need to have upstream phoc guessing user intention and hardware performance.

@dos @letterus @agx But that would only happen during animation and once there’s no movement it would go back to full resolution, right?

@js @letterus @agx Nope. It would be kinda like changing your screen's resolution to a lower value.

@dos @letterus @agx That would be extremely terrible as text becomes illegible. I would much rather see something like dynamic reposition as it is in modern video games.

@js @letterus @agx Reasonably sized text on 360x720 at 5" is hardly illegible. Just run any XWayland app where such scaling happens already and see for yourself.

Nevertheless, the compositor has no contextual knowledge on what's being displayed. Every client would have to implement that by themselves.

@dos @letterus @agx It’s very much illegible and if there’s no movement, there is also no reason to downscale. The compositor is very aware of how many FPS it is able to draw and adjust accordingly?

@js @letterus @agx How many FPS the compositor can draw is irrelevant. How would you distinguish between a wl_shm backed surface that legitimately updates ten times per second and a client that struggles to render and ends up with 10 FPS?

@js @letterus @agx BTW. The first iPhone had a screen with resolution even lower than that (320x480) and with comparable DPI.

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml