PS—This is really handy for some naive plot animations (re-rendering) that I've been playing with, thanks for the tip. It looks like the GTK IDE supports this too (once gtkwd has been loaded); any caveats on usage?
On Sat, Aug 31, 2013 at 8:58 PM, Marc Simpson <[email protected]> wrote: > Thanks Bill—this is probably preferable as the double buffering on OSX > seems to require qApp->processPendingEvents() anyway, impacting > performance on other platforms. > > Agreed? > > On Sat, Aug 31, 2013 at 8:43 PM, bill lam <[email protected]> wrote: >> wd'msgs' can enable Qt to process pending events, eg >> >> step1=: 3 : 0 >> for_n. i.y do. >> smoutput'Step' >> wd'msgs' >> 6!:3]1 >> end. >> ) >> step1 5 >> >> >> Сб, 31 авг 2013, Marc Simpson писал(а): >>> Hmm, it seems that repaint() doesn't behave identically on Linux and >>> Mac—under OS X, the patch appears to have no effect (Qt 4.8.5). >>> >>> On Sat, Aug 31, 2013 at 7:29 PM, 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 >> >> -- >> regards, >> ==================================================== >> GPG key 1024D/4434BAB3 2008-08-24 >> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
