4 ms·
Interesting since Windows used to have GUI events only going to the main thread. Window graphics contexts / rendering contexts generally a main thread thing as
by rs23296008n1 7y ago
Interesting since Windows used to have GUI events only going to the main thread. Window graphics contexts / rendering contexts generally a main thread thing as well.
Has that changed?
Asserting "no main thread" implies any thread can post and receive events to/from the OS with no proxies. Sounds good.
- olodus 7y agoSomewhere in the thread he mentions that they on Windows have a thread that is somewhat "special" but that it does as little as possible and that this isn't needed on the consoles.
- flohofwoe 7y agoA game engine only needs very little interaction with the underlying OS windowing/event APIs, usually just open a window and handle a minimal number of input- or change-events. That code can easily be isolated into a very small module doing a minimal amount of "per frame work". My guess is they do window creation and window system event handling on "some" thread, maybe the same where main() lives, maybe a different one, but the amount of work this thread does each frame is so minimal (compared to all the other stuff) that it doesn't "deserve" a special designation. I think what the tweet actually implies is that they don't have a main thread in a sense of a "main system controller thread" which invokes several systems in sequence (e.g. AI, physics, rendering), and those systems are parallelizing their work internally, but instead define the "per frame work" as one big dependency graph of small jobs/tasks without high-level syncpoints between systems. Speculation on my part though. PS: I wonder how well traditional debugging works in such a highly granular system.