Interesting—I'd be interested in hearing the motivation here too.
On Sat, Aug 31, 2013 at 8:17 PM, Don Guinn <[email protected]> wrote: > Before J6 wasn't the display and keyboard handled in a separate thread from > the j.dll? Since then the keyboard and display aren't live when J is not > waiting for input. This has resulted in things like having to run a > separate program to signal a break instead of directly from the keyboard. > This also means messages don't display in a timely manner for long running > programs, as in this case. > > I was never sure why it was necessary to make this change as I never saw > any response problems in J5. Putting the Qt interface in a separate thread > might actually simplify the interface. And, now that multiple processors > are now common on personal computers, might actually be faster as the j.dll > wouldn't have to wait for Qt to paint the screen. > > > On Sat, Aug 31, 2013 at 7:59 AM, Marc Simpson <[email protected]> wrote: > >> Slower, but not sluggish, on my machine. With 1000 "steps" and no >> delay, I'm returned to the prompt in 2.3s; without the patch, this is >> more or less immediate ~0.2s (via 6!:2). I don't think such behaviour >> is particularly surprising as we're requesting the UI be updated >> following J output rather than allowing Qt to optimise for a later >> repaint (later being the primary issue here). Incidentally, j602 and >> the patched j801 take roughly the same amount of time, so this isn't >> necessarily a performance regression if the outlined behaviour is >> considered correct. >> >> Generally speaking, repaint() is discouraged where update() will do: >> "We suggest only using repaint() if you need an immediate repaint, for >> example during animation. In almost all circumstances update() is >> better, as it permits Qt to optimize for speed and minimize flicker". >> Unfortunately, update() "does not cause an immediate repaint; instead >> it schedules a paint event for processing when Qt returns to the main >> event loop"—which is precisely what I'm trying to work around. >> >> Are you able to test on Win32 and benchmark against j602 and the >> current qtide master? >> >> Best, >> Marc >> >> On Sat, Aug 31, 2013 at 6:47 PM, bill lam <[email protected]> wrote: >> > I'm not familiar with qt IDE, just curious, will un-buffered output make >> it sluggish because of the time taking for repaint? >> > eg. Loop for one thousand times and without the delay. >> > >> > On 31 Aug, 2013, at 8:29 PM, Marc Simpson <[email protected]> wrote: >> > >> >> Terminal output is currently buffered until control is passed back to >> >> the user. For example, executing the following verb: >> >> >> >> step=: 3 : 0 >> >> for_n. i.y do. >> >> smoutput'Step' >> >> 6!:3]1 >> >> end. >> >> ) >> >> step 5 >> >> >> >> causes the IDE to hang for 5 seconds, then blit out 5 'Step's. (The >> >> GTK IDE behaves identically.) >> >> >> >> One possible fix: >> >> >> https://github.com/0branch/jqtide/commit/2aca7699961e06dd858dee109d65cdaaa397a730 >> >> -- here, Term is repainted after output, thereby providing more >> >> immediate feedback and behaviour in line with jconsole & j602. >> >> >> >> Thoughts? >> >> >> >> Best, >> >> Marc >> >> ---------------------------------------------------------------------- >> >> 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
