Bill,

Hm.  That is a perfectly reasonable request but...I do not in fact have a 
simple script.  (Part of my challenge is that the script in question is quite 
rich.)

When you indicate that the both halves of the app should be responsive, can I 
infer that my tentative explanation (that the isigraph “hogging” all of the 
core’s cycles) is unlikely, and that the two components should be equitably 
sharing the core?

I know for a fact that the isigraph needs all the cycles it can get its hands 
on.  I believe my Mac runs at 60fps (which is therefore the upper bound of the 
isigraph control’s frame rate)—but, most of the time, the control runs at 
closer to 20 fps—indicating that it’s got the core pegged.

I’ll develop an exemplary script and post it.

Many thanks.

Ed

> On Mar 22, 2023, at 5:52 PM, bill lam <[email protected]> wrote:
> 
> jqt is single threaded but it should be responsive for the scenario that
> you described. Can you post a simple script to exemplify the behavior?
> 
> On Thu, 23 Mar 2023 at 6:36 AM 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

Reply via email to