[UI] Re: Transcript>>show: slowness.
Gary Chambers
gazzaguru2 at btinternet.com
Sun Sep 9 21:37:03 UTC 2007
I'm with you Sig. As anyone that hopes the Transcript will provide some
guidance...
> -----Original Message-----
> From: ui-bounces at lists.squeakfoundation.org
> [mailto:ui-bounces at lists.squeakfoundation.org] On Behalf Of
> Igor Stasenko
> Sent: 09 September 2007 10:04 pm
> To: Squeak's User Interface
> Subject: Re: [UI] Re: Transcript>>show: slowness.
>
>
> On 09/09/2007, Bert Freudenberg <bert at freudenbergs.de> wrote:
> > On Sep 9, 2007, at 22:05 , Igor Stasenko wrote:
> >
> > > On 09/09/2007, Bert Freudenberg <bert at freudenbergs.de> wrote:
> > >>
> > >> On Sep 9, 2007, at 21:31 , Igor Stasenko wrote:
> > >>
> > >>> On 09/09/2007, Bert Freudenberg <bert at freudenbergs.de> wrote:
> > >>>> On Sep 9, 2007, at 15:11 , Igor Stasenko wrote:
> > >>>>
> > >>>>> I want to ask, if someone knows, why transcript (or maybe
> > >>>>> underlaying
> > >>>>> morphs) designed in such manner, that it forcibly
> updates itself
> > >>>>> on screen at each #show: message sent.
> > >>>>
> > >>>> So that you can see log entries even if you are in a longer
> > >>>> computation that blocks the UI.
> > >>>>
> > >>> Just read your sentence more carefully! :)
> > >>> "computation _blocks UI_". Blocks means: no input , no output!
> > >>> Since transcript window is the part of UI, so why you think it
> > >>> should make an exception?
> > >>
> > >> Because it's useful, maybe? Who cares about Transcript
> performance
> > >> if it is "pure" but useless?
> > >>
> > > I care, because i want to trace some stuff in my drawing
> code. But i
> > > can't do that because each call to #show makes transcript window
> > > being redrawn.
> >
> > Right. Do not use Transcript for that. "'some string'
> display" works
> > nicely. You could even write your own Transcript view for such uses.
> >
>
> I found where the problem buried. Its in
> PluggableTextMorph>>update: code. Transcript notifies its
> dependants, causing
> PluggableTextMorph>>update: #appendEntry get called.
> And if you look at the code, there is '^self refreshWorld' at the end.
>
> So, its not a transcript in particular, but all windows/views
> which use PluggableTextMorph class. Marking a text morph
> changed (by sending 'self changed') is enough to ensure that
> morph will be redrawn next time in the world update cycle. I
> see no point in updating it immediately making out-of-the
> order drawings which can be time consuming.
>
> Please, provide some arguments, to show the real need in
> updating screen more often than world cycle does (each 20
> msec). Will user notice difference?
>
> > > And also, if you want your computation to not block UI, you can
> > > always do: [ myStuff doSomething ] fork.
> > >
> > > Take a look, how MC works. Do you find it convenient that during
> > > updating/dowloading and installing package from net you can't do
> > > anything because all UI is blocked?
> >
> > You realize this is entirely besides the point of this discussion?
> >
>
> It was an example how people making poor code by not taking
> into account, that UI must be responsible during some long
> process which sometimes leads to failures (when connection
> lost /compiling errors). I strongly presume that such code
> must run in background. And by doing so, you eliminating both
> problems: hang UI and need of forcibly updating something on
> screen, because UI process is not blocked and updates screen
> in regular way, as it supposed to be. So, from this point,
> current discussion topic is just a small subset of wider
> problem, which we currently have with UI.
>
>
> > - Bert -
> >
> >
> > _______________________________________________
> > UI mailing list
> > UI at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
>
>
> --
> Best regards,
> Igor Stasenko AKA sig. _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>
More information about the UI
mailing list