Hmm, what does that mean for instance for workloads that use gstreamer's whepsrc? Is there a risk of incompatibility of a whep server running today with next year webrtc?
I want my desktop app https://ossia.io which uses ffmpeg to be able to send & receive video to another computer over internet without having to fiddle with opening ports on each other's routers. This combined with a server like vdo.ninja solves that.
But you do that in OGL in any case. Most software dealing with that large an asset base does so using the old fashioned shared context style threading.
It’s all gonna come down to how fast is your IO and how fast is your memory. 6 secs to load all that data, be it via vulkan style threaded submissions or OGL style threading via shared context and syncing, is not likely to happen on most laptops. Even workstations may struggle to read in and generate the necessary data. Most of the reading and generation stage is usually happening entirely outside of the gpu. All of the reading. And most of the generation. Both are going into main memory first.
Again, generation will be way faster than read in assets, but most of the assets would be getting read in. That’s IO before you even make a single vulkan or OGL call. No way around it.
Eh, having built a whole codebase around these configuration objects I really regret not going for more traditional DI IoC container. It's thousands over thousands of additional parameters passed all over the place when creating objects just for the sake of saving five minutes of explanation to newcomers.
But it did. Painter used to be a trade where you could sell your painting skills as, well, a skill applicable for other than purely aesthetic reasons, simply because there were no other ways to document the world around you. It just isn't anymore because of cameras. Professional oil portrait painter isn't a career in 2025.
and instead we have photographers who can document the world at a great volume. My Grandparents had no visual record of their wedding. My wife is a wedding photographer...
>Painter used to be a trade where you could sell your painting skills as, well, a skill applicable for other than purely aesthetic reasons, simply because there were no other ways to document the world around you.
Source? If anything I suspect there are more people making a living as painters now than at any point in history.
How do you implement an app that displays all the keys you type on screen then no matter which Wayland compositor? (For when you're making video tutorials of an app)
What you are suggesting is overstepping 2 security boundries for unpriviledged apps/processes:
1. Reading global key presses
2. Drawing in an always-on-top window with transparent content
Both these things would require that process to get special user/compositor opt-in permissions and integration. Your best bet would be using compositor plugins/native integration, or maybe you could hook into some toolkits (this is usually what FPS overlays do, hook into the graphics APIs).
That is at least my current knowledge and there might be already some wayland extensions/XDG-portal that allows it, but not to my knowledge.
It's a gotcha to be sure. Sometimes it does, sometimes it doesn't. From a reference[0]:
#include <string>
struct T1 { int mem; };
struct T2
{
int mem;
T2() {} // “mem” is not in the initializer list
};
int n; // static non-class, a two-phase initialization is done:
// 1) zero-initialization initializes n to zero
// 2) default-initialization does nothing, leaving n being zero
int main()
{
[[maybe_unused]]
int n; // non-class, the value is indeterminate
std::string s; // class, calls default constructor, the value is ""
std::string a[2]; // array, default-initializes the elements, the value is {"", ""}
// int& r; // Error: a reference
// const int n; // Error: a const non-class
// const T1 t1; // Error: const class with implicit default constructor
[[maybe_unused]]
T1 t1; // class, calls implicit default constructor
const T2 t2; // const class, calls the user-provided default constructor
// t2.mem is default-initialized
}
That `int n;` on the 11th line is initialized to 0 per standard. `int n;` on line 18, inside a function, is not. And `struct T1 { int mem; };` on line 3 will have `mem` initialized to 0 if `T1` is instantiated like `T1 t1{};`, but not if it's instantiated like `T1 t1;`. There's no way to tell from looking at `struct T1{...}` how the members will be initialized without knowing how they'll be called.
reply