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

[Igor Stasenko]

On 10/09/2007, karl <karl.ramberg at comhem.se> wrote:
> Igor Stasenko wrote:
> > 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?
> >
> The ui is not being updated till after the process is done.


> >
> >>> 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.
> >
> I think filing in code is the reason to block the ui.
>
Then its the reason of blocking everything running in image, not just
UI process.
Also, you could block only the parts which is really needed to be
blocked, like installing new classes/modifying existing. But at
downloading package?

> Karl
> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>


-- 
Best regards,
Igor Stasenko AKA sig.