How close would this be to native performance? Will it use any hardware features to reduce the emulation overhead if both the host and the guest use the same architecture?
Is the hot reload in Platform Studio limited to just UI changes or can any code in the project be hot reloaded? If the latter, what are the limitations?
> You can set it up yourself on these providers or you can use our managed service.
Are all the bits and pieces necessary for starting one's own managed service open source? In case somebody is interested in starting their own commercial cloud. How easy would that be to deploy?
There's OpenStack. It's a private IaaS. Had loadbalancers, ipv6 support, support for K8s hosting via the magnum component (and other container orchestrators), HA via Masakari component. The networking is very flexible. It does not currently have functions as a service, I believe that was in the Senlin component, but that's been abandoned, I believe a new incarnation of the idea is in the works though. With something like Kolla-ansible a containerized OpenStack infrastructure is pretty damn easy to manage, upgrades are just making sure you make any needded changes in the global config file (just a vimdiff with the new sample one included in the release) and then literally just a kolla-ansible upgrade -i inventory-file.yml.
I'm just a home labber and I've run OpenStack via kolla-ansible for like 7 years now, and Ceph since the jewel release I think almost 8 years ago for storage. Both are pretty easy to manage.
Could you be more specific with what the browsers aren't exposing properly? Because in my experience, targeting WebGL+WebAssembly is pretty much exactly the same as targeting OpenGL+GLFW. I use my own renderer made with bare OpenGL + C++ though, not Flutter. All the things you have mentioned (scroll amount, overscroll behavior) are under the control of the GUI library and don't have much to do with what the browser exposes. The compositing of the whole scene is done by the gui library itself
I use Firefox, Sway, Linux, laptop with precise touchpad.
Normally, I get smooth scrolling at such-and-such a rate of pixels-per-centimetre, with momentum so-and-so, and since comparatively recently, particular overscroll behaviour.
On that site, I get janky scrolling at a somewhat slower rate, with no momentum, and no overscroll. (… and scrolling leftwards in the carousel triggers go-back-a-page rather than scrolling left, so you need to scroll right a little first to “unstick” it, but I believe this is something Flutter could have worked around.) It’s painful. Very painful.
It’s not possible to fix this within the scope of browser mouse events. They’re just the wrong primitive. The consequence is that you can only get native scroll behaviour if you use an actual scrolling area. Which you could do, with mild compromise to the pure-canvas approach, just an invisible one and watch what happens with it, rather than paying attention to scroll events. And that’s pretty much the approach you need to use to get good results: compromise on pure-canvas, and do bits and pieces with actual DOM. For scrolling. For links. For images. For text. For inputs. Oh… huh, look at that, we actually just want real DOM stuff everywhere. Fancy that.
Now you might not immediately get such a bad experience for scrolling: I seem to recall hearing that Safari on macOS basically implements inertia before sending the events, and sends the events with inertia applied. That solves some problems, but causes others.
Actually, I meant two distinct things by “overscroll behaviour”:
① Does it let you scroll past 100% a little and then pull it back, as is increasingly normal, or show some indicator that you’ve reached the end, like Android has historically done, or just do nothing, like all computers historically did?
② Scroll chaining, the CSS overscroll-behavior property, to do with nesting scrolling areas. And note that different platforms behave differently. If you do pure-canvas rendering, you’re stuck: the browser has some of the details needed (and is unlikely to ever tell them: they’re involved implementation detail that varies by platform), and you have some of the details needed, and you can’t really collaborate, it’s just not a good mixture.
When I speak of the browser being a compositor, I refer to how scrolling is no longer implemented in a blocking fashion in the UI thread; these days it’s in a different thread, so that it can implement viewport scrolling independently of content rendering, in order to maintain consistent frame rate even in the presence of slow drawing. Also to do various other tricks to avoid missing frames, mostly platform-specific and involved. Web content will never get that power.
Do you really clearly see an image with colors stably without it easily disappearing? I can only kind of pretend I see something and then in a way see it through the pretending :)
Yes. The somewhat nice property of rust having guaranteed memory safety has been blown out of proportion so much that even though C++ with smart pointers and a bit of bounds checking is quite likely not to have memory safety issues, the comunity has decided that anything less than a guarantee means the language is unfit for any purpose and no new projects should ever be started in it. As if Java/JS/C# don't have null reference exceptions occurring all the time and to me those seem quite similar to segfaults. But I guess people are only specifically alergic to memory unsafety.
