New Renderers for GTK
blog.gtk.org
blog.gtk.org
For the time, it was just jaw dropping. For context, I think it was before Atom, VS Code or Electron (or possibly even NodeJS?) was a thing.
Don't know if that HTML renderer is still around or not.
It might not sound impressive in 2024 but back then, it was a huge deal. Very daring to even attempt something like that IMHO.
It was a time of YUI, jQuery, ExtJS, script.aculo.us and such.
I mean cool, yes....but it wasn't generating DOM elements/complex HTML or anything like you're trying to sell it as.
https://docs.gtk.org/gtk4/broadway.html https://www.phoronix.com/news/GTK4-Broadway-Being-Used
I did not considered it as main/official backend but it is still there and was ported to Gtk4.
Back then, I did run Open Office in Firefox and it amazed me.
[1] https://gitlab.gnome.org/jpu/cambalache
[2] https://blogs.gnome.org/xjuan/2021/05/18/merengue-cambalache...
https://github.com/qbittorrent/qBittorrent/tree/master/src/w...
Maybe later they moved to canvas. Or like I said, I might be mistaken.
Recently however, Flutter had two backends for web. One HTML based and other canvas based.
Some WebGL etc might be in the works.
https://github.com/moondev/gtk3-docker
My use case was running a browser inside a browser to easily interact with Kubernetes clusterip services without needing to port forward or proxy.
Another awesome example: running virt-manager to run a vm via the gtk virt-viewer (and interacting with it through the browser)
(a) using browser scrolling (the web doesn’t expose the right primitives to make a scroll-event-based reimplementation anything but bad, barely noticeable in some configurations but painfully broken in some of the most common configurations);
(b) using browser text rendering (strongly preferably by DOM nodes, but even canvas plus fillText can be acceptable); and
(c) handling links with real <a> elements (no alternative can provide the same functionality).
Broadway fails all three of these (reimplementing scrolling, rendering text on the server and sending images, and I think actually locking up when you try to click on a link). It also fails my fourth and fifth tests, which are (d) handling text input properly (it looks like it just uses key events, not even a backing <input> or <textarea> or contenteditable, so IME composition fails completely and keyboard navigation will presumably be GTK rather than native); and (d) having a meaningful accessibility tree (preferably backed by normal DOM stuff, but not necessarily; I place this one last despite its importance because it’s likely to be more retrofittable than the others, though it’ll still generally be hard).
I’d count Broadway as suitable for tech demos and for personal use where you know you don’t mind its limitations, but not for any sort of public deployment. It’s basically just an RDP/VNC sort of thing, with a smattering of DOM use. (Also remember that’s how it works—the code is all running on the server.)
I agree that real links should always be used to represent links, but if you were to emulate links surely it wouldn't be that hard? Just allow middle-clicking and ctrl-clicking and you should have the basic functionality. Is stuff like the ability to drag a problem?
And then beyond that, well. Right click or long press, browser context menu with things like copy, bookmark, open in new tab, open in private window, share… you can’t emulate most of this at all. And hover to see href in the browser’s status bar. And so it goes on.
No, the only acceptable technique is to have the user interact with a real HTML <a>, HTML <area> or SVG <a> element.
Edit: I have replied from an older state of HN, and haven’t yet seen your other comments. Fair enough, didn’t think hard enough of other edge cases, thanks!
There's some fancy bridging modes to run apps in a browser, but the author has also been working on a way to make wasm Wayland apps run directly in the browser tol.
It's bad enough this happens in GNOME (ugh). Not another faux pas in GTK please.
Now we just need proper support in Wayland and we'll finally have support for HiDPI in all major Linux DEs.
So it's just as impossible as thumbnails in the file picker? The insanity of the GTK and the resilience of people willing to put up with it is baffling to me.
GTK doing something right , doesn't suddenly absolve it of all the wrongs. And just because something is FOSS doesn't mean it's not without fault and therefore without criticism.
Sorry, maybe I was rude, but someone needs to call out BS claims like this as they probably have enough "yes men" tooting their horn.
Do they, though? Does it have any effect at all, other than potentially demotivating volunteer contributors? And if so, do those effects outweigh the negative effects?
Devs could have implemented thumbnails in file picker over a decade ago, but Gnome leadership was always against it.
Toxic and poor leadershipof such large projects should be openly criticized and pointed at, and not allow to hide and be gaslighten behind the "poor small volunteer devs".
Please stop this bullshit.
And is there anywhere where we can see that this elite leadership suddenly changed their minds on allowing this, rather than a developer seeing an opportunity when a bunch of things got deprecated, which had been postponed for a long time because it creates a lot of work for downstreams [0]?
Or is the fact that they didn't want to haphazardly break those downstreams the poor leadership you speak of?
[0] https://blog.gtk.org/2022/12/15/a-grid-for-the-file-chooser/
If you're designing a mainstream product that's not just targeting professional SW developers who can contribute back with code, but also average users who will only use it but never contribute, then you will need to be open to mainstream levels of feedback that represent the average user and not just programmers.
Otherwise let's keep complaining Linux and FOSS alternatives have only ~2% market share that it's somehow the users' fault for only buying Microsoft/Apple and not the projects' for being stubborn to feedback and out of touch with their mainstream users.
One way to tell if you should care about an opinion is to check and see if the person professing it has taken any concrete actions toward getting the world to align with it.
Thankfully large projects generally have feedback loop systems to figure out how to parse that feedback.
The rest of your comment isn't particularly contributing to the discussion here, short of trying to re-cement a broken take.
Regarding FOSS, I think some users forget that they're at a free lunch and are unpleasant and insistent about their complaints as if they were paying. They're not entitled to service and don't seem to realise it.
As to whether everyone else should listen - sure - but nobody is forced to work overtime just to right some wrong in OSS software because person A was very upset about it.
https://aur.archlinux.org/cgit/aur.git/tree/gtk3-filechooser...
Also, why isn't that patch in an MR to GTK (if the author wanted to upstream it)?
As for the Mr, again there were a few of them and it's very easy to find. https://gitlab.gnome.org/GNOME/gtk/-/issues/233#note_106497
The whole thread is full of people actively writing, fixing, rebasing code, creating MRs for years
These MRs do a minimal change to just add thumbnails. The current file manager uses outdated widgets. Gnome/GTK expects MRs to also replace deprecated widgets in all files touched by that MR. Replacing those deprecated widgets would require a massive refactor.
But they're not the same people as the ones that blocked specs and PRs by stating this was "impossible".
Blocking valuable improvements with an absolute statement like that makes contributing to such projects feel like fighting against windmills.
So from where I sit, one might as well not make them. (And I'm pushing back a bit to hopefully support the contributors who I'm grateful to.)
A honest „thank you“ to the people which made the thumbnails possible would be helpful. And involving itself. Or spending money. Gtk and GNOME are not companies. People need a motivation - from their work or from outside.
These are large entities made up of people, same as companies, not individual devs making a side project. Does that mean their work should not be criticized because their collective is not a registered publicly listed company?
>People need a motivation - from their work or from outside.
Also feedback. And that was my feedback, candid as it may be.
Like I said below, FOSS work doesn't mean it should automatically be excluded form criticism, especially if that FOSS work is so big and influential enough that it ends up having impact on other products and on people's work and lives, like Gnome being the default on most free but also commercial distros.
So please let's stop attacking and gaslighting critics, as if GNOME is some teenager developing his first app for free in his bedroom who should only be defended and praised for encouragement, instead of the giant mammoth project with private and public funding[1] developed by vested professionals of the software industry who know very well what they're doing and should be criticized when they do something wrong or are being needlessly petty and stubborn with their decisions and arguments, besides being praised when doing something right as there's already enough of that in this topic if you read it.
[1] https://www.omgubuntu.co.uk/2023/11/gnome-sovereign-tech-fun...
And I’m happy about Linux, GCC, Vim, Coretils and Gtk in general. GNOMEs keyboard centric usage is wonderful.
That said. I’m usually sad about public long term forks. Because they are not about learning or improvement but that people often failed to communicate. Yes, sometimes their targets are just differing.
Anyone good news? Maybe Mutter will support VRR itself. And maybe battery thresholds in a user friendly way. Woohooo
No we just need convince the right people to add Type-Ahead-Find back in Nautilus and background transparency officially back in gnome-terminal. Both „back“. There is existing code for both.
Or just make a fork if you want to.
"Company" doesn't mean "business". It means a bunch of companions. Like the company in `The Fellowship of the Ring`.
People are willing and ready to spend money on quality software. It is a trillion dollar industry. Open source is an endless circle of misery that needs to be ended as soon as possible.
Keep in mind, developers strive good solutions. Users need good solutions. Companies are often happy with less reliable solutions because they are forced to be fast. And this less reliable stuff tends to stay long.
* what comes preinstalled
* a weird application
* the end
* Tabs in file-browser * fast and modern terminal (ttf-fonts, utf8, OpenGL…)
* clear concise settings
* maintained application repositories
* no „desktop“ which forces me to arrange icons (WTF?)
tabs in file browser >built in for the last 2 years, tabs can be rearranged, moved between explorer windows, etc.
fast and modern terminal >windows terminal (released 2019 and built in by default) is one of the best terminal apps on any platform. Tabs, GPU acceleration, fonts, seamless multishell support (including Linux shells local - WSL - or remote)
*maintained application repositories > winget (released 2020 and built in by default) repository is now the backend of windows store and can maintain externally installed software, just run ‘winget upgrade —-all’ in your shell of choice
Also, you can now install any linux distro you want with a single click using WSL, with full x11 and Wayland support. If there’s a Linux app you prefer, you can use it seamlessly. You can even run a full desktop. I’d almost go as far as to say that nvidia hardware is supported better through WSL, where latest drivers “just work” and I’ve never experienced things breaking, than on baremetal Linux (although that says more about nvidia than any platform).
I’m glad about the thumbnails (it was overdue by a decade) but there are many features and every new feature available is missing somewhere else[1]. Next year we will discuss either missing Flatpak support on Windows (cgroups, namespaces) or missing Vulkan on MacOS or missing built-in Android support on Linux.
[1] or not - because it doesn’t fit well. For example the weird database/library kind stuff in Explorer which teases users on Windows. I think EXPLORER.EXE has become awful hard to use. It was usable back in NT4 and NT5.
It's just sad that Gtk used to have this functionality and dropped it when Gtk3 was envisioned, as it meant the ecosystem was stuck waiting for over a decade.
I had multiple discussions here in HN with users who wouldn't believe that, given fractional scale ratios, _anything_ else than direct fractional rendering produces significant blurriness. (And note fractional rendering can also produce blurriness, e.g. through misalignment).
If your 1200 × 800 window is set to be scaled to 125 %, with the unified renderers, we will use a framebuffer of size 1500 × 1000 for it, instead of letting the compositor downscale a 2400 × 1600 image.
If that's what they are doing, that sounds like sanity finally.
I’m curious to see how much of an impact the wayland architecture will be, and if ‘gnome only’ apps become a thing.
Sidenote: I hacked the wayland protocol implementation for gnome into working at least for SteamVR, but at least with AMD gpus there is some serious bug preventing the card from performing properly. It basically throttles itself for no reason and never hits the refresh rates needed for smooth VR, especially since there is no asynchronous reprojection at the moment. So while ideally the drm-leasing problem would be solved already there are other even more important problems to solve with linux VR for now.
Instead of cutting its losses early and dumping X11, both the Unix vendors and open source spent far too long trying to make lemonade out of a truckload of rotten lemons. And that’s why Linux GUIs are so far behind.
It’s notable how rapidly Apple was able to evolve their Unix GUI because they were not tied to X11 and instead embraced the integrated model, even designing their own GPUs nowadays.
GNOME is probably the most polished in terms of aesthetics, animations, and gestures. The downside is that it’s much more a tablet OS experience with a few desktop affordances — kind of like iPadOS if it were turned into a desktop OS — than it is a traditional DE. As such expect for various power user features to be diminished or absent compared to macOS or Windows. Pantheon also ranks highly here, with similar limitations.
KDE comes in second. Compared to GNOME it still has a number of rough edges in terms of aesthetics but is comparable to Windows in terms of overall capabilities and design.
Third would be Cinnamon, which attempts to blend a more Windows-like desktop with GNOME-like polish, but last I knew this project is understaffed which has resulted in it falling behind a bit. Also requires X11, unlike GNOME and KDE which work well with Wayland.
Trying to separate X from the client/server model would be like saying: "I like Unix just fine, except files and processes and the shell and the software tool philosophy, really." — You just don't have much left.
I also disagree that the client/server design is a problem. Modern graphics hardware is remote from the CPU for all intents and purposes. So remote buffer manipulations protocol is exactly what is needed.
But, a few days ago, I finally switched over, on a modern machine (~ 6 months old), with a modern OS (more than modern -- I'm running a pre-release version). And now, finally, I see what all the fuss is about. Wayland is absolutely beautiful. The rendering and animations are gorgeous, and so so smooth. The whole system is far faster, far more robust, and far more efficient both in computing resources and workflow than anything I was ever able to achieve on X.
I have been using Linux on X11 displays as my primary machine since 1996. I do development work, but not with graphics, where I'm just a regular user. I don't really care about how good the design is or how hard it is to write programs using X / Wayland / whatever. All I care about is how usable my system is. And for me, having reached the Wayland promised land, I now understand what I was missing with X, in a way that I could never have before.
Tear-free rendering, all the time, every time. Frame perfect windows, all the time, every time. A desktop that finally feels immediately responsive, all the time, every time. Under X11, all those round trips to and from the X server add milliseconds to response time, hard to benchmark, but very easy to feel. Worse yet, X11 responsiveness is variable. If the system is loaded, your desktop can lag so badly under X. This doesn't happen with Wayland.
I now have OSD volume controls that work even when the screen is locked. This was never possible with X, and can never be possible.
I now have a lockscreen that, guaranteed, will not leave my desktop unlocked if someone crashes it by feeding it malicious input. X11 is architecturally incapable of providing such guarantees. There were several instances of security bugs where lock screens in X11 crashed in exactly this way.
Wayland has now reached the point where it is a must-have for me. If it doesn't run Wayland, I won't buy it, and I won't install it. Yes, X11 works well after all these years, but Wayland is enjoyable to use in a way that X11 never was.
There are some old applications on Windows that aren't DPI-aware and look weird, but usually fixable. It's still a million times better than whatever X11 does.
IMO macOS is the only OS where graphics and fonts work the exact way one would expect reliably.
The rest, not so much. Applications work only if they do the right thing. Applications could do the right thing on X11 too. They don't just like the "old" applications on Windows.
Anyway, you've dragged this away from the general points: issues with Linux GUI toolkits have little to do with XWindow, and Apple's GUI toolkits have had to evolve just as the Linux ones have.
I've hard-coded some DPI settings for certain apps that I always display on the same monitor.
Meanwhile, I have zero issues with the same pair of monitors on Windows and macOS. I daily drive all 3 of them.
I disagree. Other platforms did similar things where clients would command the OS what it should draw and the OS would handle all app's rendering which allowed for good performance on primitive hardware. Like other display severs X did evolve to also be for passing around framebuffers of what the app drew once hardware became capable. X's problems come from being hard to maintain, being a monolith of unrelated concepts, having poor security, etc.
Apple rapidly evolved their GUI because they are trying to support just the one. And, frankly, they are starting to buckle on the idea that they are fully coherent.
Direct3D on Windows: app renders something and calls IDXGISwapChain.Present. The implementation communicates with the desktop compositor running in the dwm.exe process, dwm.exe renders the entire desktop composed of multiple windows, then communicates with physical GPU to wait for next vertical blank event.
Bare metal Linux with DRM: app renders something, calls drmModePageFlip(), then waits for next vertical blank event with poll() and drmHandleEvent() functions. Embedded Linux developers did an amazing job about DRM/KMS, in my experience the API is both reliable and efficient.
X Window systems have multiple different methods, glXSwapIntervalEXT, glXSwapIntervalMESA, glXSwapIntervalSGI, but in practice none of them is reliable, and on some systems none of them is even supported. Unfortunately, this makes rendering tear-free 3D content on X11-based desktops hard-to-impossible.
Hardware accelerated 3D graphics is the best way to render pretty much everything on modern hardware, games or not games. High-resolution displays are omnipresent. Even cell phones often have FullHD or more pixels, like 2796×1290 or 2556×1179 in the iPhones.
https://learn.microsoft.com/en-us/windows/win32/direct2d/com...
Specifically, WPF is based on DirectX 9, Direct2D is based on Direct3D 11, UWP and WinUI are based on Direct2D. On my computer, both Chromium and Firefox browsers are using Angle on top of D3D11, Firefox uses Direct2D for canvas only.
Also, even legacy apps who render their GUI with GDI are still using 3D GPUs to an extent. Some GDI operations like BitBlt are accelerated internally by the OS. And the OS composes windows on the desktop with D3D11, dwm.exe process does that.
A counterexample is video playback. The best way for video is to use the hardware decoder and hardware compositor. You don't want to render the video texture to a quad. Using the hardware compositor requires less computation and less power than using 3D graphics.
Not according to Microsoft, see that page https://learn.microsoft.com/en-us/windows/win32/medfound/how...
Microsoft strongly recommends that new code use MediaPlayer or the lower level IMFMediaEngine APIs to play video media in Windows instead of the EVR, when possible. Microsoft suggests that existing code that uses the legacy APIs be rewritten to use the new APIs if possible.
That lower level IMFMediaEngine API they recommend for Win10+ delivers uncompressed video frames in D3D11 textures.
Which in the best case is done via hardware decoding as I said.
The composition is done by the 3D GPU like I said. Either in your app if you render that video yourself, or if you supply a swap chain’s back buffer to IMFMediaEngine.TransferVideoFrame method, dwm.exe will do it.
That’s how modern Windows does that in practice. Everything does go through the 3D graphics pipeline, and starting from Win8 it’s impossible to disable.
I’m not even sure modern PC hardware supports these hardware layers, except for one small extra layer for hardware mouse cursor. On my computer D3DCAPS_OVERLAY and DDCAPS_OVERLAY flags are unset. The driver reports to the OS the hardware doesn’t support any hardware overlay surfaces.
Yes, they do. I'm guessing you may be using an older nvidia gpu. In the case no overlay is available the video can become fullscreen and to take the only layer from dwm. For pcs the benefit is less about performance / power and more about lower latency.
Why are you so certain?
> you may be using an older nvidia gpu.
Tested AMD Vega 7 inside Ryzen 5 5600U, and nVidia 1080Ti — dxcapsviewer.exe shows the same result, no overlays are supported. Only the D3DCURSORCAPS_COLOR hardware cursor is there.
> the video can become fullscreen and to take the only layer from dwm
Indeed, exclusive D3D full-screen mode allows to bypass dwm.exe compositor, even on modern Windows. But I don’t think it’s evidence of any hardware composition being used.
Look at documentation from GPU manufacturers, look at GPUs that support multiplane overlay on windows.
>But I don’t think it’s evidence of any hardware composition being used.
It's not, but it doesn't require using 3D graphics to put the texture on the display.
According to Microsoft, MPO is an optional feature: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
According to random people on the internets, the feature is broken for both nVidia and AMD: https://www.reddit.com/r/AMDHelp/comments/yr5dda/can_someone...
nVidia agrees and recommends disabling MPO with a registry setting: https://nvidia.custhelp.com/app/answers/detail/a_id/5157/~/a...
> it doesn't require using 3D graphics to put the texture on the display
In practice, 3D graphics is the best way to put pixels on the display. At this point, I believe other ways are remnants of the old GPUs which had 2D blitting hardware.
I wonder if a UX toolkit could be completely declarative and semantic - "I need a master/detail view, a list view with the following fields, some actions, ...". At the high level you don't give any positioning, or styling. It would automatically use the appropirate system widgets. Then on top you would add some polish by using a bit of CSS, or maybe an escape hatch to get the native widgets.
Almost everything that is not a browser, a WYSIWYG editor, or a media viewer would fit that mould. The kicker is that from such a description you could easily generate a TUI.
A symptom is that you have tags like "Rectangle" and attributes like "Margin". The high-level description shouldn't say anything about presentation, just what you want to accomplish. The building blocks should be like "CRUD Editor" or "List-Detail view".
It would probably have been a good idea to track performance throughout the implementation and iterate on that instead of "architectural purity".
> Proper color handling (including HDR) > Path rendering on the GPU > Possibly including glyph rendering > Off-the-main-thread rendering > Performance (on old and less powerful devices)
(Which is not to say that tracking performance isn't a good idea. It's just that "architectural purity" sounds needlessly dismissive to me.)
I don’t think I get your point here. Gtk 4 is retained-mode whatever renderer you use; Vulkan and OpenGL are immediate-mode (well, kinda) whatever renderer you use. Whatever problems that forces in the new renderers would be just as present in the old ones, wouldn’t they?
Vulkan and OpenGL, though, are in no practical sense immediate mode: You need to draw the whole frame every frame (barring a few exotic extensions for compositors and such), so you need to retain the state of everything in the frame so you can draw it.
> You need to draw the whole frame every frame
This isn’t even true at a high level. You can composite buffers. That’s not exotic. That’s a fundamental operation.
But insofar as needing to actually do all your draw calls at once - that is literally what "immediate" in immediate mode means.
> Vulkan and OpenGL
They don’t specifically retain state - they’re immediate. That’s what immediate mode means. What something higher up does has nothing to do with it.
What would you even consider immediate mode by your definition?
> so you need to retain the state of everything in the frame so you can draw it.
That state can be a procedure and a handful of variables (which in the extreme is all a shader). The point is Vulkan and OpenGL have no say over the nature of that state.
I guess I'm looking at it from a GUI application programmer POV. That OpenGL or Vulkan are, themselves, immediate mode, doesn't matter all that much there. Drawing happens on the GPU, which wants to process large buffers without changing its state in between. An overview of all drawing operations (scene graph, proper use of the term retained mode) with batching and merging is needed to cater to that. Examples: Qt QML scene graph, GTK4 GSK
> You can composite buffers
Compositing buffers is still drawing, though
> What would I consider immediate mode?
Basically, a canvas-type thing. You just scribble wherever whenever (limited by convention and correctness, of course) and what you don't touch stays like it is. Drawing happens on the CPU, which is fairly happy to do small operations at the drop of a hat. No need to remember any state for the benefit of the graphics API. Examples: Qt QPainter, GTK < 4 using Cairo
> No, the new renderers are not faster (yet).
If you see a noticeable performance decrease:
> GSK_RENDERER=gl
I'm ok with performance leaning on advances in the hardware. I'm also ok with performance dropping if you are pushing more pixels. But, we had high resolution displays years ago. Such that that is a tough hill to defend.
Is why nobody says that old "3d" games like Doom were poorly implemented. Even if they were not fully 3d.
(which CPU? render what? using how much of the available CPU power? with how many frames of latency allowed?)
Note that I don't fundamentally disagree with you and I cringe when I hear issues dismissed as "premature optimizations" myself.
While yes it would be great if a community could raise funds, that coordination job itself would have to become someone's not-paying-the-bills work.
As much as I love Open source/Free/Libre software and am grateful it exists (and contributing to it, when possible), I've a long held belief that it is the pursuit of the privileged. You need to have the privilege of free time and then the privilege of being able to choose to spend that free time on something that doesn't improve your standard of living and then the privilege of being able to do it consistently.
I benefited a lot of Open Source in my career, life so I am very thankful for all contributors (and try to give back in money/time, when I can afford one or the other).
What really annoys me, that my government does not mandate that software build with tax money must be Open Source.
That would go a long way to fund Open Source and improve the quality.
¹: https://download.fsfe.org/campaigns/pmpc/PMPC-Modernising-wi...
²: https://www.admin.ch/gov/fr/accueil/documentation/communique...
³: https://joinup.ec.europa.eu/sites/default/files/inline-files...
In principle, yes. In practice, most of the "community" is paid developers for companies like RedHat. So while they do have to pay the bills, they do so by those FOSS contributions.
That said, in the context of what the OP was saying, unfortunately, this is a chicken-and-egg situation. For someone, like the OP, who would like to get paid to do OSS, they'd need to have a reasonably active OSS presence prior to being hired at places like Red Hat. Which is another aspect of my original point of contributing to FLOSS being the pursuit of the privileged.
I'm not saying that's the correct approach for GTK, just noting is not an absurd idea.
And FOSS devs always create non-hideous maintanable code that everybody understands /s
Edit: In particular, Matthias Clasen, the guy blogging here, has been with Red Hat for many years.
> If the community can organise a regular budget to pay for such devs, then you’d see a significant rendered snd toolkit updates. Same with other open source apps.
So if you care and feel the call, go organize something. I care, but have other duties.
I'm very skeptical that a bunch of game developers are going to whip together something that crushes Skia in performance without sacrificing a ton of capabilities.
I am not sure, if I understand you right, but do you mean rendering to pdf or svg instead of the GPU?
If so, are there real world use cases?
"crushes Skia in performance without sacrificing a ton of capabilities"
Same question, what of those capabilities are really in use and needed? Linux GUIs in general are really not a beacon of light, in terms of performance or usability. I strongly suspect things could be better, if some bloat would be removed.
I am amazed with what is possible with PixiJS, a renderer for the Web, using WebGL and soon WebGPU. Having something simple, but powerful as the base, would be my way to go.
SVG is vector graphics, when you already have pixels - there is no clear way going back.
("Easy" assumed, there is already something there)
(Sorry, I am having flashbacks of the debate with X and wayland, where it was argued, but X is network transparent, except that it wasn't anymore since a long time and, or because - no one used it)
Having features is nice, but not if they are not really necessary and come at the cost of the core feature (performant screen renderer).
If performance was the primary concern, GTK and QT, would not be generations behind (a claim I am skeptical of.)
UI toolkits have a much larger audience than the tiny corner of the industry you work in.
Step one: get the knowledge out there. Have those developers at least, I don’t know, talked about what makes those toolkits better at GDC?
>I sincerely hope this attitude does not creep into FLOSS and Open Source more then it already did
If you took away people working on FOSS because they're paid to, that wouldn't contribute or drop to 1/10th the rate otherwise, you removed the most prolific and important maintainers and contributors of lots of huge FOSS projects.
The primary difference between professional firefighters and their volunteer counterparts is hours on the job. When I graduated from the state academy, I knew as much as about firefighting as any of my fellow graduates and had been through precisely the same training requirements. However, the gap is going to open up very rapidly since the career guys will be doing regular shifts every week, whereas I will be answering 1-3 calls a month on average, most of which will not be fire-related. A year from now, the career guys will be even more familiar with everything we learned during our certification training and more, while I will be working hard to remember any of it.
So the question is: how well does this analogy hold for s/w development?
It doesn't.
First of all, the gap between most proprietary development outcomes and their FLOSS equivalents has more to do with UI/UX design questions than actual coding skills. At the source code level, it's generally proprietary projects that are "burning down left and right" (shoddily and quickly built, with inadequate attention to engineering and insufficient caring about one's work due to marketing deadlines).
Secondly, the difference between proprietary developers and their FLOSS equivalents in terms of hours of experience is not deterministic. It's going to be a function of employers, personalities, life situation. Plenty of (typically younger) FLOSS developers squeeze in more quality hours on their FLOSS work than their proprietary cousins do.
Thirdly, a firefighter only gets to put out the fires that actually happen. A software developer can pick their own problems and goals and work on them at any time. There's no relationship between the outside world and your ability to advance your skills and knowledge.
2D graphics have very little in common with game engines. The problem is very different in many regards. In 2D, you generally have Bezier and other splines on input, large amount of overdraw, textures coming from users complicate VRAM memory management. OTOH, game engines are solving hard problem which are irrelevant to 2D renderers, like dynamic lighting, volumetric effects, and dynamic environment.
Edit: but then again, Pixi uses the HTML canvas element for text drawing, which uses the browsers text capabilities. So yes, at some point and somewhere those functionalities need to be implemented
Canvas is almost always the wrong choice if you want to do layouts.
And I don't use cacheasbitmap, but do my own caching. (Not because I knew of flaws, but because I was already doing it)
And for text I really recommend BitmapText. That is fast. (But not possible with all use cases, sure)
Also Pixi8 with WebGPU will be stable soon, looking forward to it.
But all in all I am really impressed, I used quite a few other js graphic engines before and Pixi was by far the best. Or which one did you find better?
What is needed for performance of traditional GUI app rendering? I'm particularly interested in table rendering. Glide and Perspective are both canvas based renderers, but I haven't dug into the internals.
https://www.factorio.com/blog/post/fff-251
If you think you could contribute you can apply for them.
I guess you will probably find there are already brilliant and competent people working on this stuff and the problem is not so easy as you believe.
None of these apply to a generalist renderer, therefore it can only "lag behind" the game ones. (Unless maybe if we're talking about the "human side of the question" : what are the best designs, layouts for a generalist human/machine interface ? Here it's the generalist GUIs that I would expect to be a couple of generations ahead (Xerox' labs, Apple's Macintosh, IBM's Common User Access standard, CERN's World Wide Web...)
https://news.ycombinator.com/item?id=39151000
comes to mind...
GTK/Qt are usually good/very good with their integration with the OS, accessibility feature, keyboard navigation, handling of features like copy/paste, ... These are the kinds of things that game ui toolkit tend to completely forgo since they don't need it, and focus instead on performance, theming, integration with a game engine, ...
Theoretically, you could say that the renderer is agnostic with this, but in practice, it is not completely true. And also with the simple fact that you have a limited budget to work on feature, and they both rather work on different feature. Having a very fast and accurate renderer is just not as important for desktop GUI framework than for game UI toolkits.
Text is also the bane of renderers--there is a reason why we have exactly 3 text shaping engines--Windows, Apple, Harfbuzz. Text is a beast to deal with and is often ill-specified.
Text is also the bane of GPUs--we don't have good GPU-only algorithms for taking a string of text, handing that to the GPU, and having the GPU render that directly to a buffer.
Text is also something that games suck at rendering. SDF (signed distance fields) are considered a good rendering of text in the 3D world and they are blurry as hell.
I do think that the modern GUI world is going in a lot of wrong directions, but you must deal with text accurately to call yourself a real GUI.
Also, you say they are a couple of generations ahead, but do these kinds of software need to be bleeding edge? Even many games don't, the kinds of software in research labs that do pay even better than gamedev (and of course require PhD's and whatnot).
Thanks for at least replying, everyone else was just downvoting.