[UI] Re: Transcript>>show: slowness.

[Gary Chambers]

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
>