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

[karl]

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.

Karl