Trinity keeps KDE 3 on life support

Posted May 20, 2024 16:34 UTC (Mon) by flussence (guest, #85566)
Parent article: Trinity keeps KDE 3 on life support

> Though the Trinity web site claims compatibility with newer hardware, it had some significant issues with a high-resolution (HiDPI) laptop display and external monitors over Thunderbolt connections. For example, on a 13" laptop display with 2256x1504 resolution, TDE's user-interface elements were too small to use comfortably.

That's a shame. I would've hoped it could handle exotic dot pitch better than that since KDE3 existed in the era of high end workstation CRTs and things like the T220, and sidestepped the entire content-consumption HDMI race to the bottom.

But maybe it's for the best. Those Keramik widgets are now a reasonable size on screen.

Trinity keeps KDE 3 on life support

Posted May 20, 2024 17:23 UTC (Mon) by epa (subscriber, #39769) [Link] (5 responses)

Does it respect ye olde X11 dpi setting? That was the natural way to support higher pixel density, but as I recall GTK summarily dropped support for it and fixed it at 100 -- just in time for high-res displays to become affordable. (not sure about Qt)

I guess that Qt 3, while it's old, is not so old that it uses X11 server-side fonts. Which leads me to another question: how does TDE perform over an X11 remote session? Many newer applications end up painting the window pixel by pixel and can be unusable over X11, even on a fast local network. Does the older toolkit work better over the traditional X11 remote protocol?

Trinity keeps KDE 3 on life support

Posted May 21, 2024 18:10 UTC (Tue) by Elv13 (subscriber, #106198) [Link] (2 responses)

The problem isn't so much about the bitmap/framebuffer rendering as it is about "damage" area, animations, composition and accelerated rendering. Almost nothing from this millennium uses the X11 server side GUI primitives. If you use a simpler theme without too many fancy elements and damage area is exposed properly, then SSH+X/VNC/RDP/SPICE is pretty quick regardless. In Qt4/Qt5 era, you had a few rendering backends to pick from. Raster and X11 perform better depending on the scenario/protocol. In later Qt5/QtQuick, Qt6/QtQuick and GTK4, the "default" moves toward GPU accelerated rendering. It allows fancier effects, but in practice the problem pixel density. Qt 96 DPI, classical CPU rendering is faster. At 500, the GPU becomes far better (and much more power efficient). Animation and "smoothness" is important for devices with touch screen, not so much for keyboard and mouse. Since all DEs at least attempt to handle touchscreens properly, the accelerated rendering is here to stay. Accelerated GUIs perform terribly over the wire. The better way to enable them is using the GPU video encoder and turn them into a compressed video stream, which obviously is quite convoluted.

Trinity keeps KDE 3 on life support

Posted May 22, 2024 7:40 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

I guess the ideal would be to send the GPU commands over the wire to be executed on the remote end. But you'd have a protocol strongly tied to the particular hardware in use, unless you wanted to restrict yourself to OpenGL or Vulkan or whatever. And even then the software isn't written with the assumption of high latency -- it will be much too "chatty" and too likely to make synchronous calls expecting a result before proceeding. You'd have to batch up the operations somehow.

Maybe the compressed video stream you mention could actually be a list of graphics primitives the GPU has recently executed. If both sides of the remote desktop have identical hardware this "compression" could be done by the video hardware itself transparently to the software. It wouldn't be in any way a standardized protocol, and could no longer be decoded if the hardware on the other side changes, but that hardly matters for something ephemeral like a remote desktop stream. This kind of exists for GPU-intensive applications ("NVIDIA Quadro GPUs support an RDP bypass functionality allowing OpenGL applications to be fully accelerated with remote use.") but I was thinking of your ordinary desktop applications where you want a pixel-perfect, low-latency remote display.

Trinity keeps KDE 3 on life support

Posted May 22, 2024 10:58 UTC (Wed) by farnz (subscriber, #17727) [Link]

If you're doing this, you might want to base your command stream on virtio-gpu commands with the Venus extensions; you'd need to come up with a replacement for VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING, but this gives you everything you need to run Vulkan remotely - and if you can run Vulkan, Zink gives you OpenGL "for free".

Trinity keeps KDE 3 on life support

Posted May 22, 2024 10:19 UTC (Wed) by sune (subscriber, #40196) [Link] (1 responses)

From Qt 4.4 onwards, Qt started doing 'alien widgets' which is 'widgets unknown to the windowing system', which is basically Qt painting the entire thing itself.

For at least QtWidgets applications it might still be possible to get 'old behavior' back even with qt6:

https://doc.qt.io/qt-6/qwidget.html#native-widgets-vs-ali...

It is a thing that makes apps look and feel better and faster on 'local setups' but at the cost of x11 forwarding.

Trinity keeps KDE 3 on life support

Posted May 22, 2024 21:17 UTC (Wed) by louai (guest, #58033) [Link]

Qt also still has the native X backend: https://github.com/qt/qtbase/tree/dev/src/plugins/platfor...

You need to enable the configure option and then export QT_XCB_NATIVE_PAINTING=1, see here https://github.com/qt/qtbase/blob/dev/src/plugins/platfor...

That should be significantly faster over remote X connections. I backported this from Qt4 to Qt5 many years ago for exactly this use case.