Michael Gratton writes on June 27, 2018 4:26:
The necessicity to do all DOM manipulation on the main WE-thread
(sync'ed) and the interactivity between the webpage and the GUI
allows my design to become a lot simpler if I can do sync'ed requests
between my GUI thread and the WE-thread. Async-options would require
me to keep blocking user-events and making my GUI inactive when I am
waiting for a request to finish. I was hoping to avoid this since it
would be really hard to reliably guard against this. Especially since
external events / timers also need to be blocked untill the request
is done. The last option is what I am doing now (I just choose to do
most things sync'ed).
Yeah, async calls do make things more complicated, but quite often in
the long run it's usually worth it. I'm not completely sure how
WebKitGTK handles user events and other IO between the WebView and
WebProcess, but I'm pretty sure it is all async. If so handling user
input between the two is possible, at least.
Good point. Yeah for sure, must be possible.
Thanks, Gaute
_______________________________________________
webkit-gtk mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-gtk
