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

Reply via email to