{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiej47ox5xcq7ivcwi7uzuezqeevhph2phxykb3wxstidjl4ohcuhy",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3migyteybryu2"
  },
  "path": "/viewtopic.php?t=33281&p=271689#p271689",
  "publishedAt": "2026-04-01T14:16:58.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "> I get why someone would want to try implementing e10s, though. It would help take advantage of multi-core processors more easily. Though I will say, if I wanted to do it, I would not do it the way Mozilla did it. Instead, I'd probably attempt to do it in a way that preserved XUL compatibility a bit better. Like for instance, having a root window process that uses the user's browser theme, along with any extensions that purely impact the GUI and avoid touching web content.\n\nMost benefit it gives is browser UI is being responsible while content is busy.\nBut do we ever need separate process for it? When we are using OMTC+APZ, rendering/compositing/input is already done in separate thread (not really for input, but i implemented it in SDL port).\nBoth chrome and content process runs in main thread. We already support many operations in separate threads (workers, service workers, etc).\nCan we use separate threads for chrome or content rendering?\nEven if we only run chrome in separate worker, this would allow switching tabs or navgating menu while content is busy. This might be very helpful for APZ.\nIf we run content instances in separate threads, this will work as e10s, but may share some resources\nYes. making DOMs work in separate threads might be not much easy, but if we need responsible browser, optimal for multicore systems without all e10s hacks, that would be best solution\n\n* * *",
  "title": "Platform Development • Re: e10s support question",
  "updatedAt": "2026-04-01T14:16:58.000Z"
}