151–160 of 257 posts
> I profiled the whole thing and discovered several things Well done After two years with Xcode/Swift/SwiftUI I never succeeded in getting anything useful out of the profiler.
The entire view shouldn’t be redrawn but certain views only (not the entire tree) maybe look into prevent entire view from being redrawn itself (React does this too and you can prevent redraw without utilizing useMemo by understanding it’s internals)
The post didn't go into much detail as to why it seems to be so slow. Is SwiftUI recreating an entire UI's worth of components when a state update happens?
To me that’s the red flag. That an experienced game developer wasn’t able to properly troubleshoot down to the correct level, but ended up facing a black box and gave up.
Earlier quoted context omitted.
> designers are asking for stupidly complex UI I think a mobile app should have a stupidly simple UI instead. Designers traditionally use a graphics program to design pixels. SwiftUI let’s you design layouts and components. Maybe designers should change how they design and start using SwiftUI as a design tool.
Your comment reminds me how asinine some Designs orgs have become at companies. Basically chasing fashion statements and demanding Engineers “just do it” with little consideration to the development, maintenance, and testing costs. Modern development, at some companies, can truly feel regressive at times.
Earlier quoted context omitted.
I know that the HN crowd has a weird relationship with both Apple and Google that go in two very different directions regardless of the evidence but honestly I think what you are proposing is actually a really good long term plan. Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak that should clear up the remaining issues people seem to have with it when it comes to performance…
> Flutter is currently rewriting a key part of their graphics rendering pipeline as we speak Source?
This discussion feels incomplete to me without a mention of developments in the opposing camp: Google's Compose UI framework. On Android, at least, Compose feels fully baked to us. Our shop is fully committed to new development on Compose UI; bridging tools for legacy components work great, and they work great for hosting new Compose views in our legacy framework as well. The Compose team is engaged with the communit…
I found mosaic which seems to be the compose tui library you mentioned. Any other projects you know of using compose interestingly?
Earlier quoted context omitted.
iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame. Android variants all have things that iOS can only dream of having in five years (notifications was a fun one), just spread very unevenly throughout manufacture…
The copying of features isn't one-sided. Both companies have had firsts there: https://www.popsci.com/story/diy/stolen-features-android-app... When I switched from Android to iOS in 2016, I was shocked at how little was different, and I can only assume gulf has narrowed since then. A lot of features Android users just assume iOS users don't have are there: vendor-agnostic password manager integration, Safari browser…
Any UI code running on a modern CPU should take close to 0ms to update, no matter how many buttons, toggles, sliders and shadows. For the rendering part, it depends, I'd say it should take between 0.5 and 2ms with many layers, a lot or transparency and not much care for optimization.
In my experience working with IMGUI-style libraries, it's definitely feasible to perform full layout and rendering for complex UI in 1-2ms at most. For simpler applications it should be basically free. It's depressing that people are willing to accept complex, slow layout APIs at this point considering it's been possible for stuff to be fast for a long time. Perhaps surprisingly, the most expensive part is usually te…
Earlier quoted context omitted.
I've worked on mice before and frankly I have no clue what sort of technical requirement would lead to an upside down charging requirement and disabling the functionality in the meantime. Can you explain what that reason might be? Also if most people can't just pick up the mouse and use it, it's a broken design. In my particular case, it's so much smaller than my palm that I'm sure any grip would result in RSI.
Simple, the front is not thick enough to accommodate a common port like USB or Lightning. If you put it on the sides, it defies the purpose. Changing the design to accommodate a port in the front doesn't make sense because the primary function of the device is to act as a human-computer interface and optimising the design for that purpose is paramount, charging is not a primary function but something that we have to…
Earlier quoted context omitted.
I wonder what is the technical justification for it too, if any. I mean, sure - you can save space by making it a dynamic library that is shipped with the OS but considering how immature it is, shipping a specific version of it with the app should be an option IMHO.
> I wonder what is the technical justification for it too, if any. Well, apps using it get a uniform look, that uniformly changes when the OS look is updated so that it matches it, and more importantly, they and also get to have the same widgets and widget functionality [1]. Unlike, say, Windows where you have 20 generations of MS GUI lib versions, with different looks and behavior, running at the same time, even fro…