I agree. Every Flutter app I've ever used has been noticeably janky. The absolute worst is the UI for the Google Home Hub which runs at about three frames per second and is incredibly unresponsive to touch and button input. It's as frustrating to use as the touchscreen navigation system displays in old cars, the ones with resistive touchscreens.
I like a lot of things about Flutter, but how did they develop a completely new UI framework from scratch in 2015 and not make fluid animations and fast touch response latency an absolute priority?
I interviewed with one of the flutter engineers. After a casual talk with him on how they were doing the rendering, while interesting, I had a feeling that fluter will fail. It reminded me a bit of all the HTML 5.0 on mobile efforts back in 2011-2014, which mostly failed. (React Native, was an offshoot of those earlier efforts, but even that is being slowly abandoned by the industry now).
That's what you get your company hires only leetcoders.
Sometimes domain expertise comes at expense of general expertise. (some people are super strong in one area, but not so in others). Google hires generalists, which are good at the small leetcode style problems given during an interview, but which surprise surprise are not super strong at design well thought out rendering techniques.
Hence the continuous failures in many new products.
It may have something to do with the fact that Flutter state management of the UI requires the UI to repaint completely whenever there is a change.
This makes no sense whatsoever because it goes exactly in the opposite direction of optimised graphics programming - where the ideal was to repaint the smallest portion of the screen as possible for any change.
No, that's not right. Optimizing repaint rectangles is kind of a corner case these days. It's a nice feature to have in some cases for reducing battery usage, but if you're relying on it to hit 60 FPS then you are certain to fail because there are always cases where you do have to repaint the whole screen. If you can't do that at 60 FPS you're already screwed.
Games redraw everything every frame, and yet good games have much better performance than UI toolkits generally.
Just curious but isn't the whole point of using techniques such as double buffering meant to reduce the time it takes to make an update to the screen? wouldn't that actually enable higher FPS? Why would you draw an entire screen when you could repaint just a small portion of it?
Double buffering prevents the user from seeing a half painted buffer. Instead of having the application draw directly to the screen buffer, the application draws to an offscreen buffer and the buffers are swapped only after drawing is finished. It's orthogonal to whether you do full or partial updates. (Although if you do partial updates then you're not really swapping the whole buffer, you have to do a blit to present instead and that can actually be less efficient than swapping if the swap path is really swapping, say if you're in fullscreen exclusive mode or if hardware overlays are in use). And it can only ever increase the time it takes updates to reach the screen, not decrease it, since it adds an extra step (swapping) compared to drawing directly on the front buffer.
Why would you draw the entire screen? Well, it instantly eliminates a whole class of bugs where partial updates don't match full updates. It eliminates a ton of really complex code you'd otherwise have to write to track the on-screen size of arbitrary changes separately from painting them, and skip things outside the dirty rectangle while painting. And it doesn't change your worst case performance, which is what you care about when trying to hit a fixed frame rate. Actually the worst case performance should be slightly better because you're not wasting time tracking changes when you have to paint the whole screen anyway.
So the question really is, why would you bother to implement partial updates? The only real reason would be to save power in scenarios where only a small part of the screen is changing. Which is important but not that related to responsiveness or animation smoothness, which again are about worst-case performance.
Even if you do want partial updates you may be better off simply special casing a few common things like blinking cursors or video playback than implementing a fully general change tracking solution.
Can you share your computer specs and what browser you're using?
It's buttery smooth on both my Windows desktop and Mac laptop, though both are relatively new.
On my 5+ year old 1.1GHz MacBook it's still entirely usable. Dragging windows around isn't entirely fluid, but it's not that bad for such an underpowered machine.
I'm on a 2019 16" MBP 2.6GHz i7 with a 5300M. This machine isn't a powerhouse, but it can drive 1080p240Hz + 1440p144Hz buttery smooth for a million Firefox tabs and a couple IntelliJ projects (if everything's all indexed...). On this site, I get like 10fps while doing things, clicking, moving around, etc. It doesn't even look like motion. I threw it into Firefox's profiler and it has consistent "janks" between 100ms to over 200ms. No thanks.
Perhaps we have different ideas of what constitutes "buttery smooth". I find the performance usable but sluggish. I think many people have become accustomed to this kind of performance though. Regardless, I find the design of the UI quite appealing.
Yes, I have a recent and powerful GPU with hardware acceleration enabled. I also tried this on my Windows box (i7-9700k, Nvidia GTX 1070), and if anything, it performs a little worse than my Linux box. It's definitely usable. I just have a low tolerance for sluggish software.
Just another data point here: I'm running a relatively high-end workstation on Linux/Fedora 36, and it is quite smooth in Chrome but somewhat sluggish in Firefox.
I worked on a proprietary trading app using flutter for mobile and we had zero issues whilst rendering both ticker prices and charts in real time. How is desktop so different?
5950X, 32 gigs of RAM, Win10, Firefox 98, 3080Ti (if it's GPU accelerated, I didn't look) and it's super jittery for me. It's usable, but it's not smooth at all. Dragging windows around is pretty bad.
I'm on a Framework running Arch with a 165 Hz external monitor, using Firefox, and it feels sluggish to me. It's usable, but feels like the performance I'd expect from a website. For example, grabbing a window and thrashing it around, it noticeably lags behind my mouse cursor. Resizing a window from the top is pretty bumpy. It lags behind the mouse and the repainting stutters.
You should try brave or chrome it's pretty smooth for me on a 5 year old Ryzen 1 system with 32GB memory. I don't even remember what my AMD card is, it was a mediocre card 5 years ago whatever it is.
Probably a case of having hardware acceleration turned off in the bowser, which at least for me is necessary due to issues with casting chrome windows in things like discord.
It's also perfectly smooth for me on Firefox on Linux, although my hardware is pretty performant (Ryzen 9 5900X), although normally Firefox detracts significantly from performance.
Current machine: Edge (closest thing to Chrome that i have apart from Firefox) or Firefox, Ryzen 5 1600, RX570.
The performance is passable for a graphically intensive application but entirely unacceptable for a desktop environment of any kind. In addition, it seems like it is a bit worse optimized on Firefox than it is on Chromium based browsers.
Opening 1 window and dragging it around leads to ~25% of the GPU usage (albeit i power limited mine to 50% of the total capacity), which feels insane when you consider that games running at 60 FPS use maybe ~50%. Opening up more windows, anywhere between 5-10 and dragging them around yields a similar load to rendering tens if not hundreds of thousands of polygons on screen.
Thus, i have to agree with the folks that say that this is entirely unacceptable as a desktop environment for any device, apart from when you are inclined to waste your hardware resources for no good reason. Admittedly, Flutter is better suited for this than it is for web development (in which it can be downright hostile and cause accessibility issues) and if nothing else the UI looks good, but personally that's not something that i care about.
In summary: i don't think that this would ever be an acceptable desktop environment, especially for devices that are running on battery power. Its resource usage would cripple any graphically intensive tasks in the background, unless you have really powerful hardware, which isn't the case for much of the world. Then again, in my eyes the perfect DE is somewhere along the lines of XFCE/LXDE/LxQt, so YMMV.
Edit: tested it out on my notebook as well, which has a N4000 Celeron and Intel UHD 600 integrated graphics. Even opening 1 window lagged everything considerably (on Firefox) and i have to guess that the FPS was somewhere between 10-20.
So, once again: unacceptable as a desktop environment, even with any given browser overhead. Of course, being able to run software like this in the browser reflects positively upon its portability, if nothing else, which is cool to see.
I wonder where we could get benchmarks that compare the low level rendering performance of the web vs native targets per platform. Having something like that would probably be immensely useful to be able to reason about the differences between them.
On both my Windows laptop (Ryzen 7 + 1080Ti) and Windows Desktop (Ryzen 9 + dual RX 5700 XT) machines, it is really slow. Dragging windows is unbearable and the other apps are quite laggy (such as switching views in the "media" app). Both have hardware acceleration enabled.
On my Windows workstation with a Ryzen 5800X and an RTX 3080, it is a stuttery mess on Firefox. Dragging windows happens at maybe 10 FPS, and there's half a second of input latency on everything.
My first impression upon opening this was about how fast and responsive this feels (chrome/linux)... Which actually now makes me more concerned that this experience is not consistent across users and platforms, because this leads to the dangerous "but it works for me" attitude.
Flutter has some performance issues on the web but it's much better when running natively. There's still some jank caused by shader compilation but they have plans to fix that. It's not inherent to the design of Flutter - it's actually an issue with Skia.
That said, I've only used it for smallish apps. Would be interesting to see how it works for a whole desktop.
My windows machine can run make and gcc natively. You don't need to be unix to run those platforms. I haven't watched fuchsia closely (last interfaced about 6 years ago, talked to a team member, who said that eventually it would be able to emulate unix enough to build and host a compiler).
I guess I should have put my question in a more useful way: why would I want to use this desktop, given its limitations compared to existing desktops? Is it ever going to be a development system? If not, I can't see how it would grow beyond being a device environment- in which case there probably shouldn't be a terminal anyway. Probably I'm asking for something which is not a goal of fuchsia, but in that case, I really can't get exicted about something that's supposed to replace Android and other OSes.
The UI is still quite slow. Hard to get excited about Flutter.