simscitizen

I know this type of approach was rejected at the beginning, but you can also just ask CoreGraphics to use the GPU for 2D rendering (and I'm sure there are equivalent paths in e.g. Skia or Cairo).

On macOS/iOS, the easiest way would probably be to set the drawsAsynchronously property on a CALayer. Then, all CoreGraphics operations on the context passed back to the layer via drawInContext: will be GPU accelerated.

Lastly, there are some pretty sharp edges to this API, so definitely don't go flipping it on for every layer/view in your view hierarchy.

I'm not sure if this works well for more demanding games, but recently I wanted to let my kid play Number Munchers and Oregon Trail and just built a webpage for those games using js-dos. It worked well enough for those games.

DE is definitely not meant for older computers, it contains gigabytes of 2D sprites

There's already a popular OS that disables overcommit by default (Windows). The problem with this is that disallowing overcommit (especially with software that doesn't expect that) can mean you don't get anywhere close to actually using all the RAM that's installed on your system.

Not really something anyone can change at this point, given that the entire web API presumes an execution model where everything logically happens on the main thread (and code can and does expect to observe those state changes synchronously).

I agree, all of these rules aren't the right way to teach about how to reason about this. All of the perf properties described should fall out of the understanding that both tables and indices in SQLite are B-trees. B-trees have the following properties:

- can look up a key or key prefix in O(log N) time ("seek a cursor" in DB parlance, or maybe "find/find prefix and return an iterator" for regular programmers)

- can iterate to next row in amortized O(1) time ("advance a cursor" in DB parlance, or maybe "advance an iterator" for regular programmers). Note that unordered data structures like hash maps don't have this property. So the mental model has to start with thinking that tables/indices are ordered data structures or you're already lost.

A table is a b+tree where the key is the rowid and the value is the row (well, except for WITHOUT ROWID tables).

An index is a b-tree where the key is the indexed column(s) and the value is a rowid.

And SQLite generally only does simple nested loop joins. No hash joins etc. Just the most obvious joining that you could do if you yourself wrote database-like logic using ordered data structures with the same perf properties e.g. std::map.

From this it ought to be pretty obvious why column order in an index matters, etc.

That’s exactly what he meant by using Focus Modes, which is the iOS feature that lets you do just that.

If you type the name of the person, it should allow you to create a filter for "Messages with: Person". It should also pop up a filter bubble for photos. From there I think you can type in some query and it should do a query on the photos via text. I don't think you can add your date filter though.

Second way would be to open that conversation view, click on the contact icon at the top of the view, which should then bring you to a details page that lists a bunch of metadata and settings about the conversation (e.g. participants, hide alerts, ...). One of the sections shows all photos from that conversation. Browse that until you find the one you care about.

Oh I've debugged this before. Native memory allocator had a scavenge function which suspended all other threads. Managed language runtime had a stop the world phase which suspended all mutator threads. They ran at about the same time and ended up suspending each other. To fix this you need to enforce some sort of hierarchy or mutual exclusion for suspension requests.

> Why you should never suspend a thread in your own process.

This sounds like a good general princple but suspending threads in your own process is kind of necessary for e.g. many GC algorithms. Now imagine multiple of those runtimes running in the same process.

> It is insane that we have to dedicate multiple gigabytes of RAM, have CPUs 1000x faster than we had back with Netscape Navigator

Webpages are applications. Browsers are application runtimes. The main culprit driving high memory usage is not the runtime, but the application.