5 ms·

I might not have been clear in my grandparent post. I wasn't proposing this as a means to WebKit2. (I don't know what WebKit2 is.) I was suggesting this might b

by dunham 12y ago

I might not have been clear in my grandparent post. I wasn't proposing this as a means to WebKit2. (I don't know what WebKit2 is.) I was suggesting this might be a way to get JIT support in native apps with the current iOS WebKit, by running the entire UIWebKit out of process. However, I have no idea if there are enough hybrid apps out there, with javascript performance issues, to justify going to the trouble of doing this.

eridius 12y ago
Ah. Well, it's a cute idea, but it won't work with UIWebView. Besides the fact that existing apps already rely on the fact that UIWebView isn't remote (because they can muck about with various view properties of it, including direct access to its UIScrollView), UIWebView also exposes at least one synchronous API (-stringByEvaluatingJavaScriptFromString:) and synchronous APIs are no good when doing stuff out-of-process. It also has a delegate that runs in a synchronous mode (e.g. it's asked questions it has to answer by returning a value, instead of just being notified of events or using a callback-based response), and that's the same problem as synchronous APIs (because now the remote process has to block waiting on a response from UIWebView). WebKit2 is an existing effort by Apple to do out-of-process rendering. Various desktop apps already use it, including Safari, Mail, and iBooks. It features new APIs for doing everything, because it's all asynchronous. If third-party iOS apps gain out-of-process rendering it will be through WebKit2 and not some attempt to port UIWebView to the remote view controller system. Incidentally, the same synchronous issues with UIWebView that I mentioned above suggest that porting to WebKit2 is a non-backwards-compatible change. If Apple makes this change, I would guess that either they'll introduce a separate UIWebView class that's used for WebKit2 and leave the existing UIWebView alone, or they'll give UIWebView two modes, a WebKit mode and a WebKit2 mode, and whichever mode it uses will be selected at initialization time (and using a WebKit method on a WebKit2 UIWebView would be an error, and vice versa). Either way, apps will have to be rewritten to take advantage of WebKit2.
- 0x0 12y ago
  What is it that makes a synchronous call to an out of process view on ios so bad? Also, apple has changed the internal subviews of system views before. In some cases they seem to provide a backwards compatible subview layout mode triggered by looking at the compiler/linker/sdk version so existing binaries will keep running. For sure I have seen previously working code like this breaking merely by recompiling with a newer xcode, as if it is taken to be an opt-in to new internal layouts - but not always; sometimes even existing apps needs rush updates if they have been assuming too much about undocumented subview hierarchies.
  - eridius 12y ago
    > What is it that makes a synchronous call to an out of process view on ios so bad? Because it's blocking the main thread. Worse, it's blocking the main thread doing something that has effectively no upper bound on how long it can take. Web Process is blocked trying to handle a previous request to calculate Pi to a trillion digits in javascript? Oops, your synchronous call to execute more javascript will just have to wait. Indefinitely. > Also, apple has changed the internal subviews of system views before. I'm not talking about internals. UIWebView directly exposes its scrollView as public API. And you can muck with the view properties of the UIWebView too to make changes. For example, if you really want to you could set your UIWebView to 50% alpha (and this is totally legit, not depending on internal subview hierarchies). Whereas Remote View Controllers explicitly prevent you from mucking with any aspect of the view hierarchy.
    - 0x0 12y ago
      It would still be blocking the main thread if it was in-process? I'm not seeing the big deal here, at least if there's a 1:1 relationship of web views and the out of process counterparts. And it's not like ios is running a lot of foreground apps simultaneously either. Fair enough about the scrollviews, although maybe they could be proxied somehow.
      - eridius 12y ago
        I suppose you're right in that my example of calculating pi only makes sense if you're sharing the web process with another app. But the real point, that I skipped to try and make what I thought was the more dramatic (but flawed) point, is that out-of-process requests have built-in latency that in-process requests don't. It's just plain bad design to have a synchronous API that talks to another process.
- dunham 12y ago
  Ahh yes. I had overlooked the fact that the API was synchronous.

by dunham 12y ago

eridius 12y ago

Ah. Well, it's a cute idea, but it won't work with UIWebView. Besides the fact that existing apps already rely on the fact that UIWebView isn't remote (because they can muck about with various view properties of it, including direct access to its UIScrollView), UIWebView also exposes at least one synchronous API (-stringByEvaluatingJavaScriptFromString:) and synchronous APIs are no good when doing stuff out-of-process. It also has a delegate that runs in a synchronous mode (e.g. it's asked questions it has to answer by returning a value, instead of just being notified of events or using a callback-based response), and that's the same problem as synchronous APIs (because now the remote process has to block waiting on a response from UIWebView). WebKit2 is an existing effort by Apple to do out-of-process rendering. Various desktop apps already use it, including Safari, Mail, and iBooks. It features new APIs for doing everything, because it's all asynchronous. If third-party iOS apps gain out-of-process rendering it will be through WebKit2 and not some attempt to port UIWebView to the remote view controller system. Incidentally, the same synchronous issues with UIWebView that I mentioned above suggest that porting to WebKit2 is a non-backwards-compatible change. If Apple makes this change, I would guess that either they'll introduce a separate UIWebView class that's used for WebKit2 and leave the existing UIWebView alone, or they'll give UIWebView two modes, a WebKit mode and a WebKit2 mode, and whichever mode it uses will be selected at initialization time (and using a WebKit method on a WebKit2 UIWebView would be an error, and vice versa). Either way, apps will have to be rewritten to take advantage of WebKit2.

0x0 12y ago
What is it that makes a synchronous call to an out of process view on ios so bad? Also, apple has changed the internal subviews of system views before. In some cases they seem to provide a backwards compatible subview layout mode triggered by looking at the compiler/linker/sdk version so existing binaries will keep running. For sure I have seen previously working code like this breaking merely by recompiling with a newer xcode, as if it is taken to be an opt-in to new internal layouts - but not always; sometimes even existing apps needs rush updates if they have been assuming too much about undocumented subview hierarchies.
- eridius 12y ago
  > What is it that makes a synchronous call to an out of process view on ios so bad? Because it's blocking the main thread. Worse, it's blocking the main thread doing something that has effectively no upper bound on how long it can take. Web Process is blocked trying to handle a previous request to calculate Pi to a trillion digits in javascript? Oops, your synchronous call to execute more javascript will just have to wait. Indefinitely. > Also, apple has changed the internal subviews of system views before. I'm not talking about internals. UIWebView directly exposes its scrollView as public API. And you can muck with the view properties of the UIWebView too to make changes. For example, if you really want to you could set your UIWebView to 50% alpha (and this is totally legit, not depending on internal subview hierarchies). Whereas Remote View Controllers explicitly prevent you from mucking with any aspect of the view hierarchy.
  - 0x0 12y ago
    It would still be blocking the main thread if it was in-process? I'm not seeing the big deal here, at least if there's a 1:1 relationship of web views and the out of process counterparts. And it's not like ios is running a lot of foreground apps simultaneously either. Fair enough about the scrollviews, although maybe they could be proxied somehow.
    - eridius 12y ago
      I suppose you're right in that my example of calculating pi only makes sense if you're sharing the web process with another app. But the real point, that I skipped to try and make what I thought was the more dramatic (but flawed) point, is that out-of-process requests have built-in latency that in-process requests don't. It's just plain bad design to have a synchronous API that talks to another process.
dunham 12y ago
Ahh yes. I had overlooked the fact that the API was synchronous.