In the profile details
1,464 karma · joined April 22, 2009
It's been on my radar for a long time and I have prototypes for one that are bitrotting on gitlab. There are three major design pieces of it.
First, It has an executable that runs in your development container (environment/etc) which means you can load libraries/typelibs/girs/etc just like the app would without crashing the IDE (or Glade in the old days).
Second, everything is an AST node so doing fun manipulations, unlimited undo, etc is just tree mutations.
Third the worker process does the rendering to a render node tree which is then shipped over to the Designer process to render.
The cambalache author and I are friends, so we occasionally talk about how we can make things work to integrate from Builder.
As for blueprint, that is outside of my knowledge area. I still do everything in XML and would prefer a designer to work with trees anyyway. Not sure I'd go the route of mutating a blueprint AST, but I hear it has back-and-fro to XML so that would probably be fine.
Also, if you want to make this a higher priority, lobby my employer (Red Hat) to make sure they know it's important to you.
Secondly, help me with _any_ of my other projects so I have some cycles to dedicate to it. People rarely notice but Builder, Sysprof, Text Editor, D-Spy, Manuals, Ptyxis, etc... are all one-man (split between many) projects and libraries.
Having all of my GPL code ripped out of MonoDevelop so it could become Visual Studio for Mac was the straw that made me write GNOME Builder, GNOME's flagship IDE.
If they get it to GTK 4 and recent WebKit release they'll get a lot of DMA-BUF usage to bring many of those WebKit->GTK->Compositor copies to 1 (or in some offloading cases, zero).
1. TCP streams require stalling when packets are dropped to keep the stream in order
2. X _requires_ by design that commands are performed in order
Which means that using something that can do UDP and manages it's own sequence ordering can do significantly better. This is why things like RDP, PCoIP, etc could do full frame rate HD video 15 years ago and you still can't with X protocol over the network.
Breaking up the screen into small 16x16 chunks or so, encoding on the GPU, and shipping that turns out to be significantly faster.
Especially when you take into account that virtually _nothing_ draws with X using X drawing primitives. It's almost all using Xshm for anything non-trivial.
How about input events? How about vsync synchronization? How about monitor information? How about clipboard? How about drag'n'drop?
GDK does an awful lot of lifting for Just here.
Simple as that.
Sad news for ya, flutter just wraps GDK (from GTK) on Linux. It also, last time I checked, was limited to a single application window.
If you read the article carefully, it mentions it aligns vertically to the _device_ pixel grid.
Additionally, being able to monitor container APIs in the long run will require more than file monitoring a podman json file in the user $HOME. It could connect to a socket for monitoring (like machinectl, etc).
All these sort of things really benefit from running on the host rather than the UI sandbox.
> is said agent tied to prompt or could the "container detection extras" be usable with other Linux terminals
In that it's bundled with prompt, but it's just a D-Bus API albeit on a private socketpair(). The agent is not much code though to copy.
Of course, I also wrote the glyph cache for GTK, but it's just not something I can fix there.
This of course only works because of careful selection of which GLibc API/ABI is allowed to be used. So far I've tested as far back as CentOS 7.
We built Flatpak and Builder in concert from the beginning to foster this exact outcome.
But as for language? I already hack on GTK/GDK/GSK internals in C, a mix of C++ and C to contribute to VTE, and Builder is 250k of C with another 200k in associated libraries. I'm just better at it and language bindings are never an issue.
People that know me know I'm not fond of the design of containers on Linux. But that's just because I've been stuck having to make things actually work on them. Transparent IDE support, making profilers, resolving ELFs from radically different mount namespaces, PTY API giving completely undocumented results, ...
But that said, we're stuck with them so might as well make it as pleasant as possible.
They are independent of the graphics subsystem altogether (although that is where they got their start, afaik). Your webcam also uses DMABUF. So if you want to display your webcam from a GTK 4 application, this GtkGraphicsOffload will help you take that DMABUF from your camera (which may not be mappable on CPU memory, but can DMA pass to your GPU), and display it in a GTK application. It could either be composited on the GPU, or mapped directly to scanout if the right conditions are met.
I wrote a library recently (libmks) and found the culprits in Qemu/VirGL/virtio_gpu that were preventing passing a DMABUF from inside a guest VM to the host. That stuff is all fixed now so theoretically you could even have a webcam in a VM which then uses a GTK 4 application to render with VirGL and the compositor submit the scene to the host OS which itself can set the planes correctly to get the same performance as if it were in the host OS.
> I'd like to be able to decompress video in one process or docker container on a cloud instance with an NVidia accelerator, and then pass zero-copy references
If you want this stuff with NVidia, and you're a customer, I highly suggest you tell your NVidia representative this. Getting them to use DMABUF in a fashion that can be used from other sub-systems would be fantastic.
But at it's core, if you were using Mesa and open drivers for some particular piece of hardware, yes it's capable of working given the right conditions.
GTK 3 itself was trying to lose the tech debt of 2.x (which in turn 1.x). But they were still all wrapping a fundamentally crap API of X11 for graphics in this century.
GTK 4 changed that, and it now wraps a Wayland model of API. That drastically simplified GDK, which is why I could write a macOS backend in a couple of weeks.
It also completely changed how we draw. We no longer do immediate mode style (in the form of Cairo) and instead do a retained mode of draw commands. That allows for lots of new things you just couldn't do before with the old drawing model. It will also allow us to do a lot more fun things in the future (like threaded/tiled renderers).
The APIs all over the place were simplified and focused. I can't imagine writing an application the size of GNOME Builder again with anything less than GTK 4.
Hell, last GNOME cycle I rewrote Sysprof from scratch in a couple months, and it's become my co-pilot every day.
You'll need API to remap the Drawable to the scanout plane from a compositor on a per-frame basis (so when submitting the CRTC) and the compositor isn't in control of the CRTC. So...
I don't really have time for that though, I only wrote the macOS port because I had some extra holiday hacking time.
Sure it lets you do fast 2d acceleration but we don't use 2d accel infrastructure anywhere anymore.
Subsurfaces have been in Wayland since the beginning of the protocol.
This is simply getting them to work on demand so we can do something X (or Xv) could never do since Drawables would get moved to new memory (that may not even be mappable on the CPU-side) on every frame.
And that's to actually use the scanout plane correctly to avoid powering up the 3d part of the GPU when doing video playback on composited systems.
You need to dynamically change stacking of subsurfaces on a per-frame basis when doing the CRTC.
That means you have to power up the 3d part of the GPU to do that (because the renderer does it in shaders).
Where as if you add some 9 pixels of black above/below to account for the rounded corner, there is no clipping of the video and you can use hardware scanout planes.
That's important because keeping the 3d part of the GPU turned off is a huge power savings. And the scanout plane can already scale for you to the correct size.
Also, I wrote a significant part of GTK's current OpenGL renderer.
> But GPUs change the picture entirely. From what I understand by reading the article, GTK uses GL to render in the GPU then copies the pixels into main memory for the compositor to mix with other windows.
This is absolutely and completely incorrect. Once we get things into GL, the texture is backed by a DMABUF on Linux. You never read it back into main memory. That would be very, very, very stupid.
> But in modern GPU-first systems, the compositor is running in the GPU, so there would be no reason to ping-pong the pixels back and forth between CPU and GPU memory after drawing 3D or even 2D graphics with the GPU, even when having different processes draw and render the same pixels.
Yes, the compositor is running in the GPU too. So of course we just tell the compositor what the GL texture id is and it composites if it cannot map that texture (again, because it's really a DMABUF) as a toplevel plane for hardware scanout without using 3d capabilities at all.
That doesn't mean unaccelerrated. It means it doesn't power up the 3d part of the GPU. It's the fastest way in/out with the least power. You can avoid "compositing" from a compositor too when things are done right.
> So I'm afraid Wayland still has a lot of catching up to do, if it still uses a software compositor, and has to copy pixels back from the GPU that it drew with OpenGL. (Which is what I interpret the article as saying.)
Again, completely wrong.
> Check out iOS/macOS's "IOSurface":
Fun fact, I wrote the macos backend for GTK too. And yes, it uses IOSurface just like DMABUF works on Linux.