you need to add wd'msgs' to the tight loop to enable asynchronous event processing.
sys_timer_z_ =: 3 : 0 wd 'set vocContext invalid' wd 'msgs' ) On Thu, Mar 23, 2023 at 7:09 PM Ed Gottsman <[email protected]> wrote: > Raul, > > Yes—I forgot. Modern browsers’ rendering engines are concurrent and will > recruit additional cores, so WebView is not entirely dependent on its > “home” core. Still, there is apparently something that the home core needs > to do before a page can be loaded. Below is a script that demonstrates the > problem. > > 1) Evaluate starve’' > 2) Resize the window that appears > 3) Type in a URL and press enter. It should load in the right pane. > 4) Select the “Draw Frames” check box. This turns on animation, which > tries (and fails, on my machine) to hit 100 fps. It’s doing a lot of work > per frame; the core is pegged. > 5) Type in a URL and press enter. On my machine it did not load until > I—eventually—turned off “Draw Frames”. > > This (and your comments) suggest to me that if I thread off all of the > “data wrangling” (which is considerable and could be a lot smarter) and > just leave a shared data structure that a relatively lightweight > main-thread rendering routine can turn into gl2 calls, that might fix it. > Unfortunately, the only way to know for sure is to build it. > > Thank you. > > Ed > > load 'gl2' > coinsert 'jgl2' > > buildForm =: 3 : 0 > wd 'pc vizform;' > wd 'bin h;' > wd 'bin v;' > wd 'bin h;' > wd 'cc drawFrames checkbox;cn Draw Frames;' > wd 'cc urlBox edit;' > wd 'bin z;' > wd 'cc vocContext isigraph;' > wd 'bin z;' > wd 'cc browser webview;' > wd 'bin z;' > ) > > layoutForm =: 3 : 0 > 'w h' =. ". wd 'getp wh' > winW =. w - 20 > winH =. h - 20 > wd 'set drawFrames maxwh ' , (": (<. winW * 0.15) , 30) , ';' > wd 'set urlBox maxwh ' , (": (<. winW * 0.3) , 30) , ';' > wd 'set vocContext maxwh ' , (": (<. winW * 0.5) , winH) , ';' > wd 'set browser maxwh ' , (": (<. winW * 0.5) , winH) , ';' > ) > > vizform_resize =: 3 : 0 > layoutForm '' > ) > > vizform_close =: 3 : 0 > wd 'timer 0' > wd 'pclose' > ) > > sys_timer_z_ =: 3 : 0 > wd 'set vocContext invalid' > ) > > vizform_urlBox_button =: 3 : 0 > smoutput 'Loading' ; urlBox > wd 'set browser url *' , urlBox > ) > > vizform_drawFrames_button =: 3 : 0 > if. drawFrames = '1' do. > wd 'timer 10' > else. > wd 'timer 0' > FrameTimeStamps =: '' > wd 'set vocContext invalid' > end. > ) > > vizform_vocContext_paint =: 3 : 0 > glfill 255 255 255 255 > k =. 1e7 ?@$ 1000 > drawFrameRate '' > ) > > FrameTimeStamps =: '' > > drawFrameRate =: 3 : 0 > FrameTimeStamps =: (t =. (6!:1) '' ) , FrameTimeStamps > fps =. +/ (t - 1) < FrameTimeStamps > glfont 'arial bold 24' > glrgb 0 0 0 > gltextcolor '' > gltextxy 10 10 > gltext (": fps) , ' fps' > ) > > starve =: 3 : 0 > buildForm '' > layoutForm '' > wd 'pshow' > wd 'set urlBox text "https://www.cnn.com";;' > ) > > > > On Mar 22, 2023, at 10:25 PM, Raul Miller <[email protected]> wrote: > > > > If only it were that simple. > > > > Sadly, Qt's design is such that all UI activity must happen on the main > thread. > > > > https://doc.qt.io/qt-5/thread-basics.html > > > > Looking at how the system works, I believe that this was not the > > original plan, but instead was an organic response to some of the very > > reasonable expectations about how a user interface works. > > > > Here, it's perhaps also worth noting that a typical web browser, while > > it will use multiple threads, also uses multiple processes. > > Effectively, giving control over some part of screen real estate or > > some underlying form of infrastructure to an independent program. And, > > the webview control is, roughly speaking, a web browser. > > > > -- > > Raul > > > > On Wed, Mar 22, 2023 at 6:36 PM Ed Gottsman <[email protected]> > wrote: > >> > >> Hello. > >> > >> I've got a Window Driver application whose left side is an isigraph > control and whose right side is a webview control. The webview loads pages > in response to interaction with the isigraph. > >> > >> The isigraph side is quite snappy despite almost zero optimization > effort (a tribute to the developers of the J runtime, the gl2 library, > etc.). > >> > >> The webview…is much less responsive, even when loading locally-cached > HTML. In fact, as long as the mouse is moving and frames are being > generated in the isigraph, the webview is unresponsive. Only when the > mouse pauses (and no frames are generated) does the webview load a page. > >> > >> I *think* that what's happening is that the two Window Driver child > controls share a core, and the isigraph side steals all of the available > cycles to service mouse-move events by generating frames, leaving no cycles > for the webview to parse and render HTML. > >> > >> With that in mind, it seems possible that I could improve the > responsiveness of the webview by threading off some or all of the > (considerable) work that goes into generating an isigraph frame, leaving > most of the shared core's cycles for the webview. > >> > >> I hesitate, however, before re-arranging the code because 1) I'm not > sure about the diagnosis and 2) I've worked in graphics environments where > you're not allowed to update GUI controls off the main thread and 3) maybe > there's a much simpler approach (can I somehow thread off the webview, > e.g.?). > >> > >> Comments on any part of this would be greatly appreciated. > >> > >> Thank you. > >> > >> Ed > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
