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
