Hacker News Reader

Hacker News

Comment by rramon | Hacker News Reader

Full thread

rramon

>I believe both GPUI’s and egui’s state models are dead ends for complex desktop applications.

Why do those complex Adobe clones work so well then?

View on HN

They actually don't.

Slow, laggy UI is a common source of complaint on the issues.

Examples:

https://github.com/storytold/cadcraft/issues/752

https://github.com/storytold/cadcraft/issues/874

https://github.com/storytold/vectorcraft/issues/2292

https://github.com/storytold/artcraft/issues/2409

https://github.com/storytold/photocraft/issues/9327

Don't know about the other links you've posted, but for photocraft the vast majority of those issues are from the engine that process the image itself, not about the GUI. In fact, as far as I can tell, none of the artcraft apps are that complex in terms of GUI to be slow down by any choice of GUI framework really. There could be performance differences between them, yes, but not so much.

You do realize that saying the PhotoCraft backend is also slow and buggy isn't helping your case, right?

Why not? If the raw renderer has an unoptimsied denoise algorithm, what has that got to do with egui?

They seem to be edge cases of building extremely complicated renderers (that handle varied user files/scenes) in a very short time. The projects are weeks old. The original app's renderers were built and optimised over decades against user files. I would also assume the central renderer is a 3d surface, not egui.

Generally to the contrary, I was surprised how snappy their UIs feel in normal usage compared to the apps they're replacing.

With vectorcraft loading shape libraries can be slow, but this is a background thread.

egui was a great choice given the results; also egui's wasm support is very good, which means artcraft supports wasm; i.e. they can run on a browser.

I see. Not my experience using those apps though. There are bugs but they get fixed.

You can use the UI to figure out your ideal design process manually and then hand it off to a gent next time. The cool thing about those apps is that everything in the UI works headless as well.

It's November and most of these issues were fixed two weeks ago.

This has nothing to do with egui and is app architecture and business logic being 'held wrong'. It's a classic when you don't really know what you're doing and ask a clanker to "make me AutoCAD" or "make me Photoshop". Or maybe when you don't care at the beginning.

Nothing that can't be fixed w/o changing a line of code in egui.

UI needs its own thread, operations in the backend need to be interruptable by the user, yadayadayada.

Try rerun.io or drop me a PM and I send you a link where you can d/l an alpha of my 3D modeling app mentioned in my comment above. 100% egui. Zero lag.

I ran PhotoCraft in a VM and it runs like a game at 3 fps. Very laggy.

Why are you stating something that is not true as though it were a given, and then using that unearned precondition as the basis for your question? The premise is false. Artcraft is a complete fucking trainwreck, nothing more than scamware that falls apart as soon as you poke beyond the deceptive facade that was used to build hype.

(That said, on the scale of blame for it being bad, I would say the GUI framework accounts for 0% of that and the programming methodology accounts for 100% of that)

This does not match my experience, I use gridcraft (excel), vectorcraft (illustrator) often; they work fine.

It's ~100MiB each, installs in seconds; I can point my agent at the github repo and it will be able to run it and control the apps; e.g. look at how excel spreadsheets actually render and adjust the layout.

I'm not a power user, but for my particular use cases artcraft apps are better than the original counterparts (install-size + agent control).

I've been using filmcraft for video editing and I've had no issues.

Agent does not feel discomfort from laggy UI so your point is moot.

They are already usable and get better quickly. Are you working for a competitor?

How’s accessibility?

egui has been integrated with AccessKit since a few years now

UI for CAD-style apps is not that complex. You're typically looking at maybe hundreds of visible controls at most. Of course, assuming that the rendering of the picture/parts is handled separately.

Hundreds of visible controls sounds like more complexity than you want.

These controls are largely independent; whereas the complexity being talked about here is interdependent GUI elements.

Something about every complex GUI being a spreadsheet-style calculation.

Yeah I’m not quite sure how you get to multiple hundreds.

Just visualizing the application I work on 150 seems like it would be a bit high.

It’s an immensely complicated application but most of the screen is the viewport. You have to start pushing things into palettes / menus / modals just to keep real estate open to actually look at the model!

Not really? Toolbars, a couple of tool windows with properties, menus, etc.

I can get to hundreds of elements, but not to thousands.

Some more complex web UIs can get to that level of complexity.

Well, primarily users of Adobe software don't have efficiency in mind as their first priority. It's a little different if you are making a desktop widget and it eats a good chunk of your GPU while idle.

Most of these GUI software are vibe coded so state management essentially becomes somebody else's blackbox problem.

Reply on news.ycombinator.com