Hacker News .hnnew | past | comments | ask | show | jobs | submit | hu3's commentslogin

Sorry but neither Linux or Windows lag to resize windows in any of my 4 machines.

They range from old laptops to a Ryzen 7 9800X3D workstation.

Just yesterday a friend's father needed help setting up their second-hand old laptop with an old i5 processor. I slapped KDE and there was no lag to be seen.

Bonus point that Windows and some Linux distros have sane, intuitive window management. Whereas with macOS I keep seeing someone suggesting some arcane combination of steps to do some basic things with replies to the effect of "OMG thank you so much, this needs to be known by more people!!!"


I see frame drops when opening the start menu on a clean Windows 11 install on my work laptop (Intel Quad with 32GB memory from two years ago). I have seen the same on 3D Vcache Ryzens on systems from people who claimed there was not lag or sluggishness. It was there and they saw it once pointed out, the standards for Windows users have simply gotten so low that they’ve gotten used to the status quo.

On MacOS, meanwhile, Finder refuses to update any major changes done via CLI operations without a full Finder restart and the search indexing is currently broken, after prior versions of Ventura where stable functionality wise. I am however firm that Liquid Glass is a misstep and more made by the Figma crowd then actual UX experts. It is supposed to look good in static screenshots rather than have any UX advantage or purpose compared to e.g skeuomorphism.

If I may be a bit snarky, I’d advise anyone who does not see the window corner inconsistencies on current MacOS or the appealing lag on Windows 11 to seek an Ophthalmologist right away…

KDE and Gnome are the only projects that are still purely UX focused, though preferences can make one far more appealing than the other.


If we're talking a simple "hello world" window then sure, you can resize that at 60fps on pretty much any system.

But most nontrivial apps can't re-layout at 60fps (or 30fps even).

They either solve it by (A) allowing the window to resize faster than the content, leaving coloured bars when enlarging [electron], or (B) stuttering or dropping frames when resizing.

A pleasant exception to this I've noticed is GTK4/Adwaita on GNOME. Nautilus, for me at least, resizes at 60fps, even when in a folder of thumbnails.

On the Mac side, AppKit, especially with manual `layoutSubviews` math easily hits 60fps too. Yes it was more complex, but you had to do it and it was FAST.


For all the grief they are getting GTK4/Adwaita/Gnome is doing a lot for performance and consistency of experience.

My GNOME desktop is more coherent than my Mac one at this point

My work laptop will stall on resize constantly, and I suspect it is due to the mess of security and backup software. Windows does have an ecosystem problem.

I am also baffled by the multiple control points. I can log in to mail in 3 places. Settings have 3 with different uis....it is gross.


That can be said about any project.

And VSCode as been improving since inception, hence why it ate a large pie of the market.


I think the exact opposite, this why alternatives like Zed is taking off.

Did Zed fix font rendering on low dpi resolution yet? I figured if they couldn't fix such a basic functionality for any editor, for over a year, while pushing AI to please stakeholders, they weren't worth my time. And I question their priorities even if they finally fixed it.

And did they implement debugger support?

When I need a barebones editor I reach for Sublime which doesn't market themselves as something else.

As for Zed taking off, I see a lot of vocals in some niche communities but they barely register, if at all, in large annual surveys.


You might like MonoGame. Same level of abstraction, but in C#.

https://monogame.net


Since we've stepped from interpreted language (Lua) to compiled-to-VM language (C#), let's go all the way down to compiled, low-level language (C) with Raylib!

https://www.raylib.com/


Or use raylib from luajit FFI and blow C# out of the water. Luajit can be faster than C, truly alien tech from Mike Pall.

explain that to my webgl TypeScript browser game running at 180+ FPS while rendering a large RPG tiled world with infinite procedurally JIT generated biomes, with heavy processing delegated to webworkers.

As you aren't posting code or stats I can't say much, but I'd bet a native app would still be smaller and more efficient, since you have to wrap what you're doing in an entire Chromium instance and deal with a web stack designed for documents, which is definitionally less efficient than a native alternative. Tiles aren't exactly cutting edge technology.

"Heavy processing delegated to webworkers?" That just sounds like threads but worse.


yep, native is faster for sure.

but webgl + web workers is good enough these days.

I can't share code sorry, the project got big and I have commercial plans.

But you can tell Gemini 3.1, Opus 4.6 or GPT 5.4 High to generate a demo and they do a decent job most of the times.

that's how I got started, seeing how it was possible to have good game performance with multi threaded workloads on a browser.


Nobody ever said in the thread that web is the most efficient platform, stop with your “designed for documents” trauma already.

The first post in this subthread was literally a statement that "A web-based solution is usually better performing, despite all the bloatware necessary." And you literally joined in to support that assertion against "the Electron haters."

And it isn't trauma, it's literal fact. Electron isn't used because it's technically superior to native applications, it's used because web devs are a dime a dozen. It's popular for business reasons, not technical reasons. It works "well enough," but only because computers are really fast but there's only so much slack an OS can take up when even parts of it are Electron apps, and probably vibe-coded to boot.


Meanwhile that same computer could probably run Counter Strike at 400 FPS.

Convenience. They sell very convenient shovels in a goldrush.

Or down if this research leads to a local minima.

Added to my list of things that will never be possible on iOS.

Not to defend it, but emulating Linux in WASM is possible and ought to work on iOS in a reasonably performance way. See https://webvm.io/

It will never be native though, which is the main point.

I still have high praises since one of my clients use it in production.

I personally use it's tooling part which is screamingly fast.


Ahh yes, blame the clients for a broken OS that should "just work".

> we found that GPT-5.2 cannot even compute the parity of a short string like 11000, and GPT-5.2 cannot determine whether the parentheses in ((((()))))) are balanced.

I think there is a valid insight here which many already know: LLMs are much more reliable at creating scripts and automation to do certain tasks than doing these tasks themselves.

For example if I provide an LLM my database schema and tell it to scan for redundant indexes and point out wrong naming conventions, it might do a passable but incomplete job.

But if I tell the LLM to code a python or nodejs script to do the same, I get significantly better results. And it's often faster too to generate and run the script than to let LLMs process large SQL files.


The dream is probably that the inference software then writes and executes that script without using text generation alone. Analog to how a human might cross off pairs of parentheses to check that example.

ChatGPT already does this, albeit in limited circumstances, through the use of its sandbox environment. Asking GPT in thinking mode to, for example, count the number of “l”s in a long text may see it run a Python script to do so.

There’s a massive issue with extrapolating to more complex tasks, however, where either you run the risk of prompt injection via granting your agent access to the internet or, more commonly, an exponential degradation in coherence over long contexts.


That's because abstraction is compression of information.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: