151–160 of 279 posts
Earlier quoted context omitted.
> The shit you can do with MFC is still frightening, even today. Only vaguely familiar with MFC. Elaborate?
Foxit Reader was (is?) developed using MFC.
Earlier quoted context omitted.
From a computation perspective, UI is fundamentally an incremental computation engine. Most elements are not changing from frame to frame, so you can either recompute and re-render, or be smarter about only propagating deltas. I'd like to propagate those deltas all the way to the GPU, so you reuse lots of things from the previous frame if they haven't been invalidated. I'll be writing about this in considerably more…
Wait, are you talking about deltas as in damage rects?
Earlier quoted context omitted.
I wouldn't say it 'doesn't matter'. We get by, sure; but that doesn't mean the situation is ideal. On my laptop, if I try pinch-zooming, safari seems to do bilinear scaling, and firefox CPU usage will dramatically spike. The former is noticeably ugly; the latter is bad for battery life, and may stutter if work is being done in the background (laptops and phones don't yet have hundreds of cores).
I would bet that if you profile Firefox WebRender there very little of the time is actually spent rasterizing glyphs. It takes like 10 microseconds to rasterize a small glyph, it's really nothing. Source: This is what I spent a ton of time profiling in the past. And Safari should just rerasterize glyphs while zooming. In 2022 there's no technical reason why it can't.
Earlier quoted context omitted.
Huh? That library exists, it is called Skia, it is the most premier 2D GPU (among other targets) rendering library in the world and it powers the Android UI, Chrome, Firefox and a ton of other things. See also: https://skia.org/
Skia is not GPU first. It was initially designed for CPU-only rendering, 3D GPU support was an afterthought. For that reason, the quality of that support ain’t great. AFAIK it only uses 3D GPU to compose layers.
I don't know the code well enough to find good proof, but there's a lot of GLES and I think some DX calls in there. More than if it was just composing.
Regarding Electron, i don't understand why anyone would want to go this route. I work in finance and desktop native apps (Winforms, WPF) have far more mature libraries, better performance and time to market compared to web GUIs. With Electron, we first write web apps and then wrap inside electron and then reinvent the wheel - this is so stupid.
WPF is now open source (MIT licensed [1]), and its XAML control templates provide _as data_ a full declarative description of how a native Windows control is supposed to look like (in multiple Windows themes like Aero for Win7, Aero2 for Win10, Luna + Royale for WinXP, and Classic for Win95 look and feel [2]). This includes everything like the exact colors and gradient stops and animation timing and vector shapes and…
The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…
Is there an ECS-compatible ontology for UI components?
I think the web really killed the idea of "native" widgets. I think the rise of web apps just got everyone used to the idea that controls are just going to look different everywhere. Even on macOS, practically every app I use has a very distinct look and set of widgets (vscode, photoshop, blender, spotify -- two of those are electron, but even the non-electron stuff doesn't look very much like a "mac" app anymore). A…
I think it's more a desire for branded UI rather than Web apps. Adobe wants their UIs to be instantly identifiable as Adobe, Slack wants to be instantly identifiable as Slack, MS Office as you said, etc. Personally, I doubt this benefits users (do you really need to market to people who already bought your product?) but I'm sure the logic is compelling to decision makers and it's cheaper to "design once, run everywhe…
Earlier quoted context omitted.
So that's a good point, but I'm not quite sure OO is the issue. Also - as you hint it's entirely unnecessary, I do actually believe OO is a natural match for UI because of the overlap between components. I think it's the fact in UI you have a big chunk of state, with references all over, and sometimes doing sort of 'circular references' ... Rust code starts to have a lot of the various Vec Rc Cell Box all over the pl…
> though I can't even fathom what that might be. One of the reasons why is that the notion of a GUI is ill-specified. Most ui frameworks, including the excellent ones, like QT, have corner cases where they fail. It's just that we've gotten to the point where coders kind have it in their bag of tricks to avoid these situations by defensive programming. Until we have a proper model of graphical UI, it'll be hard to mak…
Honesty though I fear in attempt to 'find' a model, we get forced upon us this FRP stuff for academic reasons of architectural purity. Despite QT's bugs, it mostly works just fine.
On Windows, the graphics story is more or less OK. The OS includes Direct2D and DirectWrite user-facing APIs. It’s now possible to implement an equivalent on all modern platforms which have a 3D GPU. An open-source example in C# https://github.com/Const-me/Vrmac#vector-graphics-engine That particular one requires GLES 3.1, but I’m sure (did it before) it’s also possible to implement comparable stuff on top of GLES2.…
The background for this is that most existing UI toolkits are a poor fit for Rust. Rust doesn't like having shared mutable state, but event-based UIs have a global event loop and can mutate anything at any time. Rust works best with strictly tree-shaped data structures, but event handlers turn trees of widgets into arbitrary webs with possibility of circular references. Rust prefers everything thread-safe, but many U…