[dmix]

This loads super fast on a phone and is very responsive.

Modern js done right can provide top tier interfaces. So many frontend let performance go by the way side when making interactive web apps.

And performance can also be UX, how things appear and the flow of the loading. Things like placeholder boxes [1] with the same size so the load isn’t janky is one good hack. The sort of thing you don’t have to care about with native apps.

[1] I’m on the fence about the value of loading icons in each placeholder, they’ll figure out something is loaded soon enough. Not need for the distraction or highlighting loading times. Errors for components are another matter.

Although of course server side rendering of everything is the ideal initial state.

[anticristi]

I think moat websites are built using the following algorithm:

  while (!website_crashes) {
    add_more_tracking()
    add_more_adds()
  }

[ricksharp]

Yeah, this is amazing. Works great even on iPhone.

Going to save this one for the next time someone says React is slow.

This worked instantly for me (just like my website, I wonder if they are using Gatsby or something else for static pre-rendering).

[jbverschoor]

Well... You're comparing performance of almost 20 year old computers to your current machine. It takes 3 seconds to start paint. The webpage is 'only' using 85-101MB ram to do nothing.

Remind you that the requirements were: 233MHz CPU + 64MB RAM

Let's say you're running a late 2019 macbook pro 13". That's:

16384MB RAM, and 1400-3900 MHz cpu (x8 threads) with 8MB cache. Which includes branch etc etc.

All that aside, it looks pixel-perfect to me, and it behaves the same afaict :-)

[ricksharp]

No, I was specifically talking about load time which is instant (compared to the majority of the internet which is not).

Also, as far as hardware is concerned, I am comparing a 14 year gap between a desktop computer of 2001 to a 2015 iPhone 6s - a 5 year old phone that still runs on battery for about 6 hours.

But that has nothing to do with load time and why most websites today can’t load in under 1 second (or even 10 seconds).

I’ve heard many complain about React performance, yet I have seen React with ssr or static rendering perform amazingly well.

My site for example loads as fast as hacker news on first page load, and then faster because of static rendering and pre-fetching, yet it has unlimited interaction.

I imagine if I profiled the performance of this demo, it would be similar.

[jbverschoor]

Open the paint example.. it actually takes a few seconds

[ricksharp]

Wow, you’re right!

That’s faster than I can remember it loading in real windows xp on a desktop (and that was installed versus downloading additional code for that module).

Impressive!

[csande17]

Funnily enough, you can actually run the real Windows XP in an x86 emulator on a recent iPhone or iPad, and the UI responds acceptably quickly: https://www.cultofmac.com/717191/run-windows-xp-iphone-ipad-...

[soulofmischief]

My goto test: Does it crash my virtual machine?

Some of the most basic websites trigger a serious (and still unresolved after years...) bug where the rendering stutters to a halt until virt-manager and all my VM windows crash. Just basic landing pages with weird animated backgrounds, etc. Nothing rich.

This app? It works almost flawlessly with little jank and doesn't even stress my browser. And it has a much richer UX!

[exikyut]

Huh.

What VM configuration and guest OSes are you using?

Exactly what is crashing? I presume qemu itself, but can't tell if you're describing BSOD type events.

Can you reproduce the crashes using qemu-system-x86_64 directly?

[soulofmischief]

qemu/libvirt/kvm stack, it happens with both virt-viewer and virt-manager at least with Spice, pretty sure with VNC too but it's been a while. On Firefox. Fedora, both host and guests.

I can reproduce the crashes by going to a number of websites. I always assumed it had something to do with OpenGL but lately it's happening on websites that I doubt are running any accelerated content. So it could be the browser's hardware acceleration.

But essentially it takes down virt-manager/virt-viewer and I have to launch another instance. The machine itself is fine but it becomes a race to close the tab before the window crashes again.

It's been a while since I tried debugging but I'm pretty sure that it happens whether or not hw acceleration is enabled in Firefox and it also doesn't matter whether the libvirt XML configuration enables OpenGL or not.

By directly, do you mean just running the virtual machine through the cli or actually setting all my configuration flags in the qemu-system-x86_64 command?

[exikyut]

Oh, THAT'S what you mean by "crashing". I thought either the guest kernel (ie, vmlinuz or ntoskrnl) or the VM (qemu/KVM) was at fault, given that description and context. Thanks very much for the clarification.

Does sound like a graphics acceleration problem, maybe also a remoting protocol issue.

I only tend to launch VMs via qemu-system-x86_64 directly, so I'm not familiar with how virt-manager works - and crashes :). It sounds like virt-manager can crash without taking down associated VMs...? I'm also interpreting "start another instance" as referring to virt-viewer, or do you mean you're starting a new copy of virt-manager over the same/old VM?

It's really perplexing this also happens with VNC.

I wonder what would happen if you enabled the normal GTK qemu window (which for reference can of course be run in Xvnc in headless scenarios, my personal Xvnc preference being TigerVNC). I also wonder what would happen if you enabled SPICE and/or VNC with the GTK window enabled.

A better start point likely to produce more interesting/orientating info might be to run Firefox inside eg an openbox session, making absolutely sure no compositors are running (including xcompmgr etc). If you still get crashes in that type of scenario something's very broken.

I'm curious what error messages appear in the virt-manager, virt-viewer and qemu error log files when these disconnects occur.

It I were serious about fixing this my first step would be building everything from source, one component at a time, verifying the issue is still present at each step; then, if everything's still crashing, pulling out good ol' printf. Ideally something obvious emerges before you get to that point :)

[soulofmischief]

> I wonder what would happen if you enabled the normal GTK qemu window (which for reference can of course be run in Xvnc in headless scenarios, my personal Xvnc preference being TigerVNC). I also wonder what would happen if you enabled SPICE and/or VNC with the GTK window enabled.

Me too. I'll report back within a few days.

> A better start point likely to produce more interesting/orientating info might be to run Firefox inside eg an openbox session, making absolutely sure no compositors are running (including xcompmgr etc). If you still get crashes in that type of scenario something's very broken.

I can look into this, too. And I'll provide virt-viewer logs but they haven't been helpful. I'll see what the other virt-related logs are saying.

> It I were serious about fixing this my first step would be building everything from source, one component at a time, verifying the issue is still present at each step; then, if everything's still crashing, pulling out good ol' printf

This was the advice given to me before from someone involved in the virt stack, and I started to do this but it turned into a lot of work just familiarizing myself with some things and I got sidetracked and eventually shelved it and just hoped it would eventually piss someone else off enough.

[exikyut]

> I'll report back within a few days.

Sure. I'll try to check this thread so often or so.

[dmos62]

I think that a reimplementation of a ~15 year old UI running on current hardware smoothly is not particularly indicative of whether or not the implementation or the software stack is efficient. It running smoothly is indicative of it being well suited for the hardware/stack it's being tested on, but that's not a high bar, especially for a 2d UI.