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

[Igor Stasenko]

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.