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
