audidude

9 ms·

61.
by audidude 3y ago
> VTE based terminals, Kitty and WezTerm are some of the few terminals that accept C1 controls by default, within UTF-8 encoded data. My recommendation would be to not use these terminals with untrusted data. It seems the author didn&#x
62.
by audidude 3y ago
Interesting. I don't work on VTE but just landed dozens of patches with no issue at all from pleasant maintainers.
63.
by audidude 3y ago
Dunno how long it's been since you used it, but I believe keybindings for this are disabled by default now and you have to toggle them on in your profile preferences.
64.
by audidude 3y ago
I really doesn't matter to be honest, because this was just to inform the theoretical upper bounds as part of my work to make VTE faster.
65.
by audidude 3y ago
Glad this Termkit prototype work is right on track then. Generated a 655MB lorem text file and it came out at 0m8.186s.
66.
by audidude 3y ago
I've heard various things about VTE over the years including: 1. They "like" xterm because i get value out of screen tearing and feeling like they can catch what is scrolling by (even though it's literally seconds slower
67.
by audidude 3y ago
It sounds like you're pretty biased, and that's fine. You do you. But I'm pretty sure that code pre-dates reliable access to vertical sync from applications. Either via XProperty notifications from the compositor, XPRESENT, o
68.
by audidude 3y ago
Author of the code in question here ... Not sure how this got off terminals and on to compilers, but here we are. Having written the profiler I used to optimize this (Sysprof), and a large portion of the OpenGL renderer that GTK uses, I kno
69.
by audidude 3y ago
What I was trying to show, and also why I have no interest in creating something out of Termkit, is just that we have a lot of low hanging fruit that can still be fixed. I'd rather do that work as part of VTE so all the applications I
70.
by audidude 3y ago
First we make it fast. Then we remove the FPS restriction. I would be very surprised if I don't manage to nuke that as part of this work.
71.
by audidude 3y ago
It's still GTK 3 using VTE and so doing the drawing with Cairo. It (VTE) has a lot of optimizations that made sense when we didn't have working GPU drivers. But for GTK 4, we can do things much differently and faster.
72.
by audidude 3y ago
I already maintain two dozen GNOME projects. I wrote a huge amount of GTK's OpenGL renderer, the profiler we use on GNOME, GNOME Builder, and a huge amount of other parts of GNOME. I've even started to fix the library that people
73.
by audidude 3y ago
The example you gave, Audacity, has a flatpak managed by one of the flathub admins, and most definitely does not include telemetry. https://github.com/flathub/org.audacityteam.Audacity
74.
by audidude 3y ago
> Much of that finesse has been lost in this new generation of GUIs built on 3D APIs where the entire window is thrown away and redrawn every frame. GTK 4 uses eglSwapBuffersWithDamage() scissor clipped to the union of the damage rectang
75.
by audidude 3y ago
GTK 4, which the author mentions in their post, uses a retained rendering model so that the UI can be rendered on GPU. Widgets snapshot render nodes which are immutable and can even be cached between frames. Those render nodes are diffed to
76.
by audidude 4y ago
Currently, they are rendered using Pango (thus Cairo) to memory and then uploaded into a texture atlas. This happens once per-glyph/font/size (plus or minus some variants for x/y alignment). You then use the "color shade
77.
by audidude 4y ago
> but isn’t certain things faster to render on the CPU still? It really depends on the context. If you look at it in a certain light, fonts are just "vector graphics" and there are ways to do that without using SDF (signed dist
78.
by audidude 4y ago
> a lot of functionality is moving into a gnome-specific library (libadwaita) Sort of? Mostly just design patterns that are explicit to GNOME. And that is primarily a response to people being (rightfully or not) unhappy that too much GNO
79.
by audidude 4y ago
> And as VS Code by popping up in more and more sites, On Linux, VS Code can't even resize without glitching and showing unrendered portions of the window like it's 1999. Nor can it kinetic scroll. Those are two expected highli
80.
by audidude 4y ago
How does that make it "not desktop"? This is literally the dumbest argument ever. It's one extra line of code. If you have the GDK X11 backend, get the XID and call MoveWindow() yourself. If you have a macOS Window, call [NSW
81.
by audidude 4y ago
> And the same situation on Linux/GTK, system uses Cairo - pure CPU rasterization library. GTK 4 renders by default using your GPU. The only part that is CPU rasterized is if we don't have an accelerated path for it (rare) and
82.
by audidude 4y ago
GTK 4 has built-in support for at-spi in it's native controls and provides GtkAccessible interfaces which you can use to make custom widgetry accessible. > I really don't see what Gnome's doing to comply with this that eve
83.
by audidude 4y ago
I have no idea which project's you're alluding to, but I'm certain they weren't on GTK 4, which is what this thread is about.
84.
by audidude 4y ago
GTK 4 allows widget to snapshot into a render-tree, which has OpenGL, Vulkan, and Cairo for software fallback rendering. It also provides diff'ing for minimal damage and all the other important bits.
85.
by audidude 4y ago
> It may do that but generally it still uses Cairo. Uh, no it doesn't. I literally wrote the GL renderer, I know what I'm talking about. > In any case GTK working on Windows and Mac is an artefact rather than something reall
86.
by audidude 4y ago
Does Cocoa draw controls like checkboxes and what not with the GPU? In GTK 4's case, drawing the widgets, CSS transitions, shadows, etc is all on the GPU. Video from GStreamer arrives as GL textures, same for WebKit integration and the
87.
by audidude 4y ago
GTK 4 renders with OpenGL, has native a11y built-in, styled with a comprehensive CSS engine, runs on Linux/bsd/Mac/windows, has bindings for almost every noteworthy language…
88.
by audidude 4y ago
That issue is literally why I have a branch integrating GLyphy. But yes, your casual drive by comment is definitely more knowledgeable than the people who work on the stuff.
89.
by audidude 4y ago
a huge amount of emoji are embedded png in font files. newer ones, however, do require more work. > figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately. this is all done
90.
by audidude 4y ago
harfbuzz creator made https://github.com/behdad/glyphy/ which i integrated into GTK a while back (but we don't ship currently, because we still do the bitmap stuff). the bitmap stuff still has major drawbacks

More ›