D5 windows feel slow

Hi,

#fileOutOn: now expects aFileOutPolicy argument. Comments still refer to
aWriteStream. Should there be a FileOutPolicy protocol?

Drag and Drop in the SystemBrowser Classes List doesnt feel right! Its
changing something you dont get to see.

Not sure if this is a bug (it was the same in D4), 0.0 and -0.0 have the
same printString.

Louis Sumberg reported that windows seem slower when closing, and I have
found this too. Dolphin5 does not feel snappy. I dont know how to quantify
this? I do have a dual screen machine, and I have spent time with D5/D4
windows on both screens comparing by eye.

I believe that what is causing the slow feeling is the time it is taking for
a covered window to repaint when the covering window is closed. As an
experiment I covered a D4 scribble window with a D4 workspace on one screen,
and the same for D5 on the other screen. The extra time taken for D5
scribble to repaint was noticeable.

I hope this helps. My machine is a Dual Celeron 500Mhz.

Thanks
Steve Waring

Steve

You wrote in message news:[hidden email]...
>
> #fileOutOn: now expects aFileOutPolicy argument. Comments still refer to
> aWriteStream. Should there be a FileOutPolicy protocol?

There was supposed to be (well actually a <sourceFiler> protocol). I think
it got lost during refactoring from the stream based system, to a seaparate
stream plus policy, to a composite filer object that incorporates the
stream. This is recorded as defect #505.

> Drag and Drop in the SystemBrowser Classes List doesnt feel right! Its
> changing something you dont get to see.

I'll record that as a defect, though until I've looked at it I don't think
I'll understand what you mean.

> Not sure if this is a bug (it was the same in D4), 0.0 and -0.0 have the
> same printString.

I don't think that is a bug.

> Louis Sumberg reported that windows seem slower when closing, and I have
> found this too. Dolphin5 does not feel snappy. I dont know how to quantify
> this? I do have a dual screen machine, and I have spent time with D5/D4
> windows on both screens comparing by eye.
>
> I believe that what is causing the slow feeling is the time it is taking
for
> a covered window to repaint when the covering window is closed. As an
> experiment I covered a D4 scribble window with a D4 workspace on one
screen,
> and the same for D5 on the other screen. The extra time taken for D5
> scribble to repaint was noticeable.

We've recorded this as defect #506. A couple of other people have noticed it
too, so it obviously needs to be investigated. We obviously don't want
Dolphin to start looking like a certain other Smalltalk (whoops, shouldn't
have said that :-)).

Thanks

Blair

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...
>
> Louis Sumberg reported that windows seem slower when closing, and I have
> found this too. Dolphin5 does not feel snappy. I dont know how to quantify
> this? I do have a dual screen machine, and I have spent time with D5/D4
> windows on both screens comparing by eye.

Please try the attached. We found that the recent fix for defect 314 was
causing ReferenceViews to recreate their referees during destruction of the
views. Since most of the system tools contain a significant number of
reference views (even just for the toolbars), this incurs most of the cost
of opening the view in the first place, only for them to be immediately
destroyed again.

This would certainly account for the slower closing of windows that people
have experienced, but we still need to determine if there are any other
areas where there is a noticable slow down.

>
> I believe that what is causing the slow feeling is the time it is taking
for
> a covered window to repaint when the covering window is closed. As an
> experiment I covered a D4 scribble window with a D4 workspace on one
screen,
> and the same for D5 on the other screen. The extra time taken for D5
> scribble to repaint was noticeable.

Did you close the workspace, or just minimize it?

Regards

Blair


begin 666 506.st
M(B,U,#8B(0T*#0HA4F5F97)E;F-E5FEE=R!M971H;V1S1F]R(0T*#0IO;D1E
M<W1R;WEE9 T*"2)(86YD;&5R(&9O<B!D97-T<F]Y+B!%;G-U<F4@=&AA="!W
M92!K;F]W('1H92!R969E<F5E(&AA<R!A;'-O(&)E96X@9&5S=')O>65D(@T*
M#0H)?"!A;G-W97(@? T*"2)3=7!E<F-L87-S(&UE=&AO9"!R969E<G,@*&EN
M9&ER96-T;'DI('1O(')E9F5R964L(&%N9"!W92!D;VXG="!W86YT(&ET('1O
M(&)E(')E8W)E871E9"P@<V\@9&\@=&AA="!F:7)S="(-"@EA;G-W97(@.CT@
M<W5P97(@;VY$97-T<F]Y960N#0H)<F5F97)E92 Z/2!N:6PN#0H)7F%N<W=E
M<B$@(0T*(5)E9F5R96YC959I97<@8V%T96=O<FEE<T9O<CH@(V]N1&5S=')O
>>65D(65V96YT(&AA;F1L:6YG(7!U8FQI8R$@(0T*
`
end

Hi Blair,

This patch has made a big improvement. When comparing D4 to D5, I could only
see a difference when closing the window, and the patch removes that
difference. I will keep an eye out for any other slow downs, but a quick
check looked normal.

Thanks,
Steve


"Blair McGlashan" <[hidden email]> wrote in message
news:[hidden email]...
> "Steve Waring" <[hidden email]> wrote in message
> news:[hidden email]...
> >
> > Louis Sumberg reported that windows seem slower when closing, and I have
> > found this too. Dolphin5 does not feel snappy. I dont know how to
quantify
> > this? I do have a dual screen machine, and I have spent time with D5/D4
> > windows on both screens comparing by eye.
>
> Please try the attached. We found that the recent fix for defect 314 was
> causing ReferenceViews to recreate their referees during destruction of
the

"Steve Waring" <[hidden email]> wrote in message
news:[hidden email]...

> This patch has made a big improvement.

Ditto, ibid, what he said *s*, and BRAVO!

Thanks, Blair.

Blair,

> Please try the attached. We found that the recent fix for defect 314 was
> causing ReferenceViews to recreate their referees during destruction of
the
> views. Since most of the system tools contain a significant number of
> reference views (even just for the toolbars), this incurs most of the cost
> of opening the view in the first place, only for them to be immediately
> destroyed again.

I, too, find that this helps a lot.  Thanks.

It'd odd though -- that code hasn't changed since D4.  Are you using a great
many more ref. views in D5 ?

BTW.  On the subject of ReferenceView, a suggestion (which I confess I
haven't really thought through).  Would it be a good idea to make the
resourceID (or the class and name separately) be a published aspect of a
ref. view ?  I don't know if it'd break anything, but if not then it would
make fixing up views that have been broken by class name changes a lot
easier (and I had to spend a couple of hours doing just that only
yesterday).

On a similar note, I've several times wanted to be able to arrange for small
changes to the referee when it is used in some context  (e.g. using a ref to
a text view, but wanting to fix word wrap on or off for that specific use).
I know there are other ways of getting the effect, but a <monadic or
<dyadicValuable> aspect that was evaluated as the view was set up would be a
rather convenient way of doing this sort of thing.  I mention it here
(rather than over on c.l.s.d) because if you think if might be worth
following up on in the future then now would be a good time to add a
dummy/placeholder instvar to ReferenceView.

> Blair

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair,
>
> > Please try the attached. We found that the recent fix for defect 314 was
> > causing ReferenceViews to recreate their referees during destruction of
> the
> > views. Since most of the system tools contain a significant number of
> > reference views (even just for the toolbars), this incurs most of the
cost
> > of opening the view in the first place, only for them to be immediately
> > destroyed again.
>
> I, too, find that this helps a lot.  Thanks.
>
> It'd odd though -- that code hasn't changed since D4.  Are you using a
great
> many more ref. views in D5 ?

Well we are, but the real issue is that ReferenceView>>model was added,
implemented as 'self referee model'. ReferenceView>>onDestroyed has always
(well since sometime in late 1997 anyway) nilled the referee _before_
supersending. It happens that the first line of the superclass onDestroy
method (in View) attempts to remove any events triggered for the view from
the model. In accessing the model, through the new ReferenceView>>model
method, the referee is lazily recreated. The net effect is that all the
reference views were being destroyed, then recreated, and destroyed again.
As you can imagine, this did rather inflate the destruct times!

> BTW.  On the subject of ReferenceView, a suggestion (which I confess I
> haven't really thought through).  Would it be a good idea to make the
> resourceID (or the class and name separately) be a published aspect of a
> ref. view ?  I don't know if it'd break anything, but if not then it would
> make fixing up views that have been broken by class name changes a lot
> easier (and I had to spend a couple of hours doing just that only
> yesterday).

The resourceIdentifier is now a published aspect of ReferenceView. A good
tip when renaming a presenter that has views that might be referenced from
elsewhere is to add a global for the old name which aliases the new name
(i.e. OldName := NewPresenterClass). This will permit the reference views to
be loaded, and when they are saved they will automatically be "upgraded" to
use the correct new class name. Coincidentally I have just been through
today replacing the "deprecated" classes we'd left in place for
compatibility reasons with global aliases. These use to cause a problem in
packages, in that they were treated as binary globals, but the packaging
system in D5 recognises global aliases to classes and handles them
specially.

>
> On a similar note, I've several times wanted to be able to arrange for
small
> changes to the referee when it is used in some context  (e.g. using a ref
to
> a text view, but wanting to fix word wrap on or off for that specific
use).
> I know there are other ways of getting the effect, but a <monadic or
> <dyadicValuable> aspect that was evaluated as the view was set up would be
a
> rather convenient way of doing this sort of thing.  I mention it here
> (rather than over on c.l.s.d) because if you think if might be worth
> following up on in the future then now would be a good time to add a
> dummy/placeholder instvar to ReferenceView.

Thats an idea, and we'll add it as an enhancement request, but I can't
promise it or anything like it will be done for D5.

Regards

Blair