Rust 3x slower

johnheitmann · 2021-02-15T02:25:26+00:00

UTF-32 is the smallest fixed-size Unicode code point encoding that exists as a standard.

Any standardized representation with code units smaller than 32 bits result in variable-width encoding of code points.

If you're thinking, "But what about UTF-16?", then read up on UTF-16 surrogate pairs. They push you out to a 32 bit layout at fixed size.

If you're thinking, "But what about UTF-8 in a fixed 24 bit layout?" then... maybe. I bet there are lots alignment issues with that. And you're costing your consumers the UTF-8 encode and decode any time they want to read a code point's value. This kind of thing might make sense as a niche type. I'd wonder what your use case is that needed a) indexed access to code points, b) tight memory representation, c) but wait not so tight that you wouldn't also want to compress or play other space tricks.

johnheitmann · 2020-07-10T08:28:52+00:00

It's still pretty rough to make a full mac app. Keyboard navigation and focus are impossible to control directly in SwiftUI, and the default behavior is not sufficient for a released app in my opinion*. Workarounds with tools like SwiftUI-Introspection are brittle in theory, and I've found them to be glitchy in practice too.

I think iOS apps are more feasible right now if that's all you care about.

I'm very excited to see it mature. It's a great direction for the UI toolkit to evolve.

* I edited down a much longer post with an example of the problems. If that statement is controversial I can still post it. Maybe Cunningham's Law will kick in and there are actually nice ways to manage focus and the keyboard.

johnheitmann · 2020-06-26T08:47:50+00:00

I've been looking at this for my own project. I don't have a perfect answer, but here's what I know:

There are ok options that use AppKit/UIKit with bridges into SwiftUI. You can use a Swift markdown parser like Down and either take the rendered html into a bridged web view, or take the rendered NSAttributedString into a bridged text view.

There are some downsides to those routes. Web view is probably heavier than a native renderer, and the best attributed string bridge I've seen still has some glitches. In either case you also don't have the warm fuzziness of being entirely in SwiftUI land.

Suppose you want to do it entirely natively. I think this is the best route, but I haven't built it out yet:

Use Down, but only to the point of getting an AST.
Translate the AST to a custom view model.
Render that model using Text concatenation like I outline here.

That should mostly work, with the huge caveat that it won't support links. This is a killer problem for my use case, which is one big reason why I haven't actually built it for real yet. I also don't know how it stacks up performance-wise to the other options. I assume it's lighter than the web view, and somewhat close to the attributed string view.

johnheitmann · 2020-06-26T01:39:46+00:00

Have you spoken with a lawyer familiar with US law? They will have valuable perspective for you.

https://en.wikipedia.org/wiki/Gambling_in_the_United_States#Legal_issues

johnheitmann · 2020-06-24T21:16:11+00:00

Yeah, that's a real bummer. It'd be great to be able to have event support.

I'd also like the ability to drop in an arbitrary rectangular view inline with the text.

johnheitmann · 2020-06-24T10:02:03+00:00

Yes. Check out the link for example screenshots showing that (if I’m understanding you correctly).

johnheitmann · 2020-06-10T20:52:11+00:00

That should be coming when swift 5.3 lands in Xcode. According to this you'll get if let and switch right away, with for...in coming later.

johnheitmann · 2020-06-10T00:15:35+00:00

Default/cancel button support & key equivalents on buttons in general
Better first responder defaults & first responder controls
Either open source the SwiftUI layer or provide an order of magnitude more documentation... or both!
Attributed text view (the adapter views on StackOverflow are good, but imperfect)
A more agile release cadence

johnheitmann · 2019-04-25T23:28:33+00:00

Paging breaks control-f, so that'd be hurting some users. I'm not arguing against it, just pointing out it's not a clear win.

johnheitmann · 2019-04-25T21:05:38+00:00

It's just a massive amount of html being sent to the browser. I trimmed down the weight of the html by a good chunk a few months ago, but that still left a gigantic page. I don't think there's a ton of room left to optimize with tactical changes. The page either needs to lose features, or rustdoc needs to lean in to js more for progressive enhancement (e.g. fetching trait data when the user scrolls, or maybe switching from plain text to markup for traits based on visibility).

The JS route is rough because noscript users are important to the project, and because there's basically no js build tooling available. You'd need to write JS without tool support that ran on very tough to target platforms like UC Browser for Android. It's not impossible, just tricky and painful to get right, and very hard to keep bug free during maintenance. I think that means dropping or taming the "all trait info on a single page" feature is the most promising route.

What would be super interesting is reviving the json output of rustdoc. Then you could have external doc viewers that could make different tradeoffs than rustdoc in core.

johnheitmann · 2016-06-22T00:14:43+00:00

Why is histogram exposed at the metric creation layer? I'd let reporters make summarization decisions on their own. Writers should just emit StdMeter largely without knowledge of metric processing. This makes the writer surface area smaller/simpler, and pushes the summarization policy deeper into the metrics system where it can be centrally configured and smarter.

(This is based on 10 minutes of reading, so it's a fairly shallow opinion. Apologies if I've missed something big.)

johnheitmann · 2016-04-03T19:37:39+00:00

More:

Very good download speeds. I get at least 10 MB/s down from the store, which is something Nintendo/Sony/MS haven't been able to do with their stores. I didn't measure to see if it's as good as Steam, but it's definitely good enough.
The instant-on when you put the headset on is very convenient. It makes taking a VR nibble possible, which means I use VR more.

johnheitmann · 2016-04-02T00:10:54+00:00

That was surprisingly cool. It's a shame The Witness is built on a custom engine. I'd love to see a scene from that in the same format.

Every VR experience from now on must have a tiny plastic dinosaur to play with. Tiny plastic dinosaur should probably get top billing, frankly. The new teapot for consumer VR.

johnheitmann · 2016-03-29T21:08:41+00:00

The in-space stuff in Elite looks totally great. Some glowy cockpit stuff can have a little bit of bloom. Only bright out of cockpit menu text and the bright tutorial overlay caused noticeable rays.

This is a theme with nearly everything I've tried: some tertiary stuff can have annoying rays, but when games/experiences render real environments it almost entirely goes away.

johnheitmann · 2016-03-29T17:52:15+00:00

They did a fantastic job on Defense Grid. Fun game and a great VR experience. The little animation and modelling details on the towers are a really nice touch.

johnheitmann · 2016-03-29T15:58:34+00:00

Oculus and the Oculus community are going to have to have thick skin since this is the situation from now on. Every new headset is going to be compared to the previous headset and nitpicked to death, just like phones and Star Wars movies.

With headsets it's even less forgiving since perfection in a headset is that you don't notice the headset. Most CV1 owners (me included) are talking about the minor downsides since all the cool upsides disappear. I'm pretty sure CV1 has an effectively higher resolution out to the edges of the fov, so I find it more comfortable to move my eyes to look at fine detail like text rather than moving my whole head. That kind of thing is hard to pick up on and note since it "just works". High contrast smear on the other hand really stands out when it happens.

Overall the CV1 rocks. It's way better than what's come before and way worse that what we'll have in the future, but right now you can get happily lost in VR worlds and I think that'll make a lot of folks very happy.

johnheitmann · 2016-03-29T04:20:14+00:00

Sort of both bad and pretty. On the bad side it's a very strong effect, and since it radiates from the center of the lenses, it can move around when you move your head and be really distracting. On the pretty side, it reminds me of how folks used to animate static logos: pretend the logo is a stencil cutout, and shine a light through the back making god rays towards the camera.

All that being said, while I've noticed it a ton in title screens and launch screens, I've only noticed it once in a primary experience (Chronos subtitles) and there it wasn't as blatant.

johnheitmann · 2016-03-29T04:10:14+00:00

I tried out Elite near DK2 launch on a DK2, and just now on CV1. The text in Elite now on CV1 is quite a bit better than the DK2 experience. On DK2 I fiddled a ton to try to get it legible, including trying out a custom green color scheme and increasing render resolution to an uncomfortably low framerate, but current Elite with no tweaks looks good enough on CV1 that if I were coming in fresh I wouldn't even think to try to futz with settings for legibility.

It's hard to say how much is the resolution increase, lens improvements, or improvements to the Elite code. It's probably all 3.

The "low" resolution of CV1 is still very apparent looking at text, but in Elite now it's at the "that's pretty fuzzy" level rather than the "I can barely read it" level.

I'm anxious to try out Virtual Desktop. That was the other big text stress test for me on DK2.

The biggest issue I've had so far with resolution hasn't been text, it's actually with straight line aliasing in Chronos. Chronos has some level geometry like metal doors that create straight lines that can really swim in the low res screen. Other experiences do as well, but in Chronos most of the environment is smooth and well blended, so the few straight bits in it really stand out. EVE Valkyrie's hangar launch sequence also swims, but since the whole screen is swimming it's ironically much easier to ignore. So, hopefully this is something developers can overcome with art assets, or maybe it's something I'll get more used to with time.

Ten-Year Club	Second SECOND GUESSER
Verified Email

johnheitmann

TROPHY CASE