Smalltalk › Pharo › Pharo Smalltalk Developers

New Pharo based on core 10318 with antialiased fonts

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

44 messages Options

123

Henrik Sperre Johansen

Re: Issue 832 feedback

The only thing which has been reported:

"Having tried it both ways, the rollback is "a must." There is probably
an argument that the updated image dos a little better with it than does
my 10303 image, but both benefit when the rollback is applied.

Bill"

I see no way to reproduce the slowdown (which I don't experience) from that information.
Care to share some more on exactly what version you are running when noticing/not noticing slowdowns + process that eliminated slowdown for you?

Gary, got any feedback?

There has been no feedback (that I've noticed) about my experience that simply saving the image would eliminate the slowdown experienced after a System... -> Software Update.

Cheers,
Henry

Stéphane Ducasse skrev:

> What is the status of that rollback?
> Because if pahro get slower we should roll back
>
> Stef
> On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
>
>
>> Sure.
>> I'd wait applying it till others can confirm that simply saving after
>> running an update does not fix their performance problems though, as
>> outlined in my last mail.
>>
>> Cheers,
>> Henry
>>
>> Stéphane Ducasse skrev:
>>
>>> can you send me the st for the reverting?
>>>
>>> Stef
>>>
>>> On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
>>>
>>>
>>>
>>>> It's strange though, for me dragging is just as slow reverting the
>>>> changes I made in a 319 image...
>>>> And filing in the .st in a 309 image, I notice no slow downs. (309
>>>> upgraded to 319 I do).
>>>>
>>>> Are we sure nothing else causes this, perhaps changes related to
>>>> events/polling frequency or something?
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>> Schwab,Wilhelm K skrev:
>>>>
>>>>
>>>>> Henry,
>>>>>
>>>>> I for one appreciate your effort, and encourage you to keep going.
>>>>> Speaking of slow machines, I have a small herd and would be willing
>>>>> to
>>>>> help you profile the problem. Give me about a month, and I will be
>>>>> in
>>>>> a position to press them into service to help with this.
>>>>>
>>>>> Bill
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *From:* [hidden email]
>>>>> [mailto:[hidden email]] *On Behalf Of
>>>>> *Henrik Sperre Johansen
>>>>> *Sent:* Wednesday, May 27, 2009 5:07 PM
>>>>> *To:* [hidden email]
>>>>> *Subject:* Re: [Pharo-project] Issue 832
>>>>>
>>>>> Sorry, just back from the pub (YAY BARCELONA!) my initial reaction
>>>>> was really:
>>>>> I'd rather see the cause of such slowdowns while resizing
>>>>> investigated
>>>>> (and fixed), but considering the time needed to accomplish that,
>>>>> rollbacking is probably a safer option at this time.
>>>>> My mind absolutely boggles that a resizing performance decrease
>>>>> would
>>>>> be the most visible effect of the changes made in that update...
>>>>> Welcome to the wonderful world of Morphic!
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>> On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
>>>>>
>>>>>
>>>>>> Yes, rollbacking probably is the safest choice,
>>>>>> As I implied in the mail, this was really meant as a experimental
>>>>>> effort, to see if people on slower machines noticed the effects I
>>>>>> was
>>>>>> (pre)anticipating.
>>>>>> I really don't see how an extra intersect: per Morph (containing
>>>>>> submorphs) can make such a big difference...
>>>>>>
>>>>>> I'll definately post another update sometime in the future, I
>>>>>> don't
>>>>>> know when I'll have to look into it though.
>>>>>> <rant>
>>>>>> To me, the way it is right now seems unacceptable, there's
>>>>>> really no
>>>>>> reason to write a "smart" drawOn: routine for morphs that are
>>>>>> likely
>>>>>> to end up as a subMorph (saaaay, the TextMorph which I started
>>>>>> investigating in the first place), as they have to redraw the
>>>>>> entire
>>>>>> area anyways.
>>>>>> This leads to a bad cycle in morph development;
>>>>>> "As long as at minimum the area we want to redraw is marked as,
>>>>>> it's
>>>>>> fine. There's no performance gain from reporting a more accurate
>>>>>> area
>>>>>> anyways".
>>>>>> So you end up with "sloppy" damage rects for new morphs, which
>>>>>> leads
>>>>>> to more to fix if it IS changed, and slower performance for those
>>>>>> whom redrawing the entire area rather than a subsection IS
>>>>>> expensive.
>>>>>> </rant>
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>>
>>>>>>
>>>>>> On 27.05.2009 19:44, Stéphane Ducasse wrote:
>>>>>>
>>>>>>
>>>>>>> Thanks for reporting.
>>>>>>> Henrik?
>>>>>>> I could rollback the changes.
>>>>>>>
>>>>>>> Stef
>>>>>>>
>>>>>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Performance of UI seems poor after 832 integration.
>>>>>>>>
>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=832
>>>>>>>>
>>>>>>>> Regards, Gary
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pharo-project mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>>>>> project
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>>> project
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>>
>>>
>> 'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009
>> at 11:39:22 am'!
>>
>> !Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front"
>>
>> | drawBlock |
>> submorphs isEmpty ifTrue: [^self].
>> drawBlock := [:canvas | submorphs reverseDo: [:m | canvas
>> fullDrawMorph: m]].
>> self clipSubmorphs
>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>> ifFalse: [drawBlock value: aCanvas]! !
>>
>>
>> !LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc
>> 5/3/2006 14:27'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front"
>>
>> |drawBlock i|
>> submorphs isEmpty ifTrue: [^self].
>> drawBlock := [:canvas |
>> (self topVisibleRowForCanvas: aCanvas) to: (self
>> bottomVisibleRowForCanvas: aCanvas) do: [ :row |
>> i := self item: row.
>> canvas fullDrawMorph: i]].
>> self clipSubmorphs
>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>> ifFalse: [drawBlock value: aCanvas]! !
>>
>>
>> !PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front, but skip my background sketch."
>>
>> | drawBlock |
>> submorphs isEmpty ifTrue: [^self].
>> drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~
>> backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]].
>> self clipSubmorphs
>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>> ifFalse: [drawBlock value: aCanvas]! !
>>
>>
>> !TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc
>> 5/31/2007 14:11'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front.
>> Draw the focus here since we are using inset bounds
>> for the focus rectangle."
>>
>> super drawSubmorphsOn: aCanvas.
>> self hasKeyboardFocus ifTrue: [
>> self selectedTab ifNotNilDo: [:t |
>> self clipSubmorphs
>> ifTrue: [aCanvas
>> clipBy: self clippingBounds
>> during: [:c | t drawKeyboardFocusOn: c]]
>> ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Carlos Crosetti-4

Re: Issue 832

In reply to this post by Henrik Sperre Johansen

I was curious about the difference between sending duratinToRun and
selecting an expression and doing "tally it", and the later presented a DNU,
even attempting to tally "1 + 1"

-----Mensaje original-----
De: [hidden email]
[mailto:[hidden email]]En nombre de Henrik
Johansen
Enviado el: Viernes, 12 de Junio de 2009 09:11 a.m.
Para: [hidden email]
Asunto: Re: [Pharo-project] Issue 832

I did some testing.

During a minute of dragging/resizing windows (Class Browser, with 7-8
other windows in the background), the extra intersect happened
approximately 6000 times.

A small intersect speed test:
a := Rectangle origin: 1@1 corner: 10@100.
b := Rectangle origin: 3@0 corner: 5 @ 50.
[1000000 timesRepeat:[ a intersect: b]] durationToRun 0:00:00:00.992

So, about 6 ms overhead added over the course of a minute...

Unless somehow there are Morphs which ends up redrawing MORE with a
consistently SMALLER damage rect, I think it'd be wise to look elsewhere
for any slowdowns experienced...

Cheers,
Henry

Stéphane Ducasse skrev:

>>>>> *From:* [hidden email]
>>>>> [mailto:[hidden email]] *On Behalf Of
>>>>> *Henrik Sperre Johansen
>>>>> *Sent:* Wednesday, May 27, 2009 5:07 PM
>>>>> *To:* [hidden email]
>>>>> *Subject:* Re: [Pharo-project] Issue 832
>>>>>
>>>>> Sorry, just back from the pub (YAY BARCELONA!) my initial reaction
>>>>> was really:
>>>>> I'd rather see the cause of such slowdowns while resizing
>>>>> investigated
>>>>> (and fixed), but considering the time needed to accomplish that,
>>>>> rollbacking is probably a safer option at this time.
>>>>> My mind absolutely boggles that a resizing performance decrease
>>>>> would
>>>>> be the most visible effect of the changes made in that update...
>>>>> Welcome to the wonderful world of Morphic!
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>> On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
>>>>>
>>>>>
>>>>>> Yes, rollbacking probably is the safest choice,
>>>>>> As I implied in the mail, this was really meant as a experimental
>>>>>> effort, to see if people on slower machines noticed the effects I
>>>>>> was
>>>>>> (pre)anticipating.
>>>>>> I really don't see how an extra intersect: per Morph (containing
>>>>>> submorphs) can make such a big difference...
>>>>>>
>>>>>> I'll definately post another update sometime in the future, I
>>>>>> don't
>>>>>> know when I'll have to look into it though.
>>>>>> <rant>
>>>>>> To me, the way it is right now seems unacceptable, there's
>>>>>> really no
>>>>>> reason to write a "smart" drawOn: routine for morphs that are
>>>>>> likely
>>>>>> to end up as a subMorph (saaaay, the TextMorph which I started
>>>>>> investigating in the first place), as they have to redraw the
>>>>>> entire
>>>>>> area anyways.
>>>>>> This leads to a bad cycle in morph development;
>>>>>> "As long as at minimum the area we want to redraw is marked as,
>>>>>> it's
>>>>>> fine. There's no performance gain from reporting a more accurate
>>>>>> area
>>>>>> anyways".
>>>>>> So you end up with "sloppy" damage rects for new morphs, which
>>>>>> leads
>>>>>> to more to fix if it IS changed, and slower performance for those
>>>>>> whom redrawing the entire area rather than a subsection IS
>>>>>> expensive.
>>>>>> </rant>
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>>
>>>>>>
>>>>>> On 27.05.2009 19:44, Stéphane Ducasse wrote:
>>>>>>
>>>>>>
>>>>>>> Thanks for reporting.
>>>>>>> Henrik?
>>>>>>> I could rollback the changes.
>>>>>>>
>>>>>>> Stef
>>>>>>>
>>>>>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Performance of UI seems poor after 832 integration.
>>>>>>>>
>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=832
>>>>>>>>
>>>>>>>> Regards, Gary
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pharo-project mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>>>>> project
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------

---
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>>> project
>>>>>>
>>>>>>
>>>>> ----------------------------------------------------------------------
--

>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>>
>>>
>> 'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009
>> at 11:39:22 am'!
>>
>> !Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front"
>>
>> | drawBlock |
>> submorphs isEmpty ifTrue: [^self].
>> drawBlock := [:canvas | submorphs reverseDo: [:m | canvas
>> fullDrawMorph: m]].
>> self clipSubmorphs
>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>> ifFalse: [drawBlock value: aCanvas]! !
>>
>>
>> !LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc
>> 5/3/2006 14:27'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front"
>>
>> |drawBlock i|
>> submorphs isEmpty ifTrue: [^self].
>> drawBlock := [:canvas |
>> (self topVisibleRowForCanvas: aCanvas) to: (self
>> bottomVisibleRowForCanvas: aCanvas) do: [ :row |
>> i := self item: row.
>> canvas fullDrawMorph: i]].
>> self clipSubmorphs
>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>> ifFalse: [drawBlock value: aCanvas]! !
>>
>>
>> !PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front, but skip my background sketch."
>>
>> | drawBlock |
>> submorphs isEmpty ifTrue: [^self].
>> drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~
>> backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]].
>> self clipSubmorphs
>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>> ifFalse: [drawBlock value: aCanvas]! !
>>
>>
>> !TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc
>> 5/31/2007 14:11'!
>> drawSubmorphsOn: aCanvas
>> "Display submorphs back to front.
>> Draw the focus here since we are using inset bounds
>> for the focus rectangle."
>>
>> super drawSubmorphsOn: aCanvas.
>> self hasKeyboardFocus ifTrue: [
>> self selectedTab ifNotNilDo: [:t |
>> self clipSubmorphs
>> ifTrue: [aCanvas
>> clipBy: self clippingBounds
>> during: [:c | t drawKeyboardFocusOn: c]]
>> ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
Internal Virus Database is out-of-date.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.12.11/2089 - Release Date: 30/04/2009
05:53 p.m.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Alexandre Bergel

Re: Issue 832

I proposed a fix in PharoInbox. Something changed apparently in the
way a compiled method may be evaluated programatically.
Issue #883

Alexandre

On 12 Jun 2009, at 17:29, Carlos Crosetti wrote:

> I was curious about the difference between sending duratinToRun and
> selecting an expression and doing "tally it", and the later
> presented a DNU,
> even attempting to tally "1 + 1"
>
> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]]En nombre de
> Henrik
> Johansen
> Enviado el: Viernes, 12 de Junio de 2009 09:11 a.m.
> Para: [hidden email]
> Asunto: Re: [Pharo-project] Issue 832
>
>
> I did some testing.
>
> During a minute of dragging/resizing windows (Class Browser, with 7-8
> other windows in the background), the extra intersect happened
> approximately 6000 times.
>
> A small intersect speed test:
> a := Rectangle origin: 1@1 corner: 10@100.
> b := Rectangle origin: 3@0 corner: 5 @ 50.
> [1000000 timesRepeat:[ a intersect: b]] durationToRun 0:00:00:00.992
>
> So, about 6 ms overhead added over the course of a minute...
>
> Unless somehow there are Morphs which ends up redrawing MORE with a
> consistently SMALLER damage rect, I think it'd be wise to look
> elsewhere
> for any slowdowns experienced...
>
> Cheers,
> Henry
>
> Stéphane Ducasse skrev:
>> What is the status of that rollback?
>> Because if pahro get slower we should roll back
>>
>> Stef
>> On May 28, 2009, at 11:46 AM, Henrik Johansen wrote:
>>
>>
>>> Sure.
>>> I'd wait applying it till others can confirm that simply saving
>>> after
>>> running an update does not fix their performance problems though, as
>>> outlined in my last mail.
>>>
>>> Cheers,
>>> Henry
>>>
>>> Stéphane Ducasse skrev:
>>>
>>>> can you send me the st for the reverting?
>>>>
>>>> Stef
>>>>
>>>> On May 28, 2009, at 10:08 AM, Henrik Johansen wrote:
>>>>
>>>>
>>>>
>>>>> It's strange though, for me dragging is just as slow reverting the
>>>>> changes I made in a 319 image...
>>>>> And filing in the .st in a 309 image, I notice no slow downs. (309
>>>>> upgraded to 319 I do).
>>>>>
>>>>> Are we sure nothing else causes this, perhaps changes related to
>>>>> events/polling frequency or something?
>>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>> Schwab,Wilhelm K skrev:
>>>>>
>>>>>
>>>>>> Henry,
>>>>>>
>>>>>> I for one appreciate your effort, and encourage you to keep
>>>>>> going.
>>>>>> Speaking of slow machines, I have a small herd and would be
>>>>>> willing
>>>>>> to
>>>>>> help you profile the problem. Give me about a month, and I
>>>>>> will be
>>>>>> in
>>>>>> a position to press them into service to help with this.
>>>>>>
>>>>>> Bill
>>>>>>
>>>>>>
>>>>>> ----------------------------------------------------------------------
> --
>>>>>> *From:* [hidden email]
>>>>>> [mailto:[hidden email]] *On Behalf
>>>>>> Of
>>>>>> *Henrik Sperre Johansen
>>>>>> *Sent:* Wednesday, May 27, 2009 5:07 PM
>>>>>> *To:* [hidden email]
>>>>>> *Subject:* Re: [Pharo-project] Issue 832
>>>>>>
>>>>>> Sorry, just back from the pub (YAY BARCELONA!) my initial
>>>>>> reaction
>>>>>> was really:
>>>>>> I'd rather see the cause of such slowdowns while resizing
>>>>>> investigated
>>>>>> (and fixed), but considering the time needed to accomplish that,
>>>>>> rollbacking is probably a safer option at this time.
>>>>>> My mind absolutely boggles that a resizing performance decrease
>>>>>> would
>>>>>> be the most visible effect of the changes made in that update...
>>>>>> Welcome to the wonderful world of Morphic!
>>>>>>
>>>>>> Cheers,
>>>>>> Henry
>>>>>>
>>>>>> On 27.05.2009 23:54, Henrik Sperre Johansen wrote:
>>>>>>
>>>>>>
>>>>>>> Yes, rollbacking probably is the safest choice,
>>>>>>> As I implied in the mail, this was really meant as a
>>>>>>> experimental
>>>>>>> effort, to see if people on slower machines noticed the
>>>>>>> effects I
>>>>>>> was
>>>>>>> (pre)anticipating.
>>>>>>> I really don't see how an extra intersect: per Morph (containing
>>>>>>> submorphs) can make such a big difference...
>>>>>>>
>>>>>>> I'll definately post another update sometime in the future, I
>>>>>>> don't
>>>>>>> know when I'll have to look into it though.
>>>>>>> <rant>
>>>>>>> To me, the way it is right now seems unacceptable, there's
>>>>>>> really no
>>>>>>> reason to write a "smart" drawOn: routine for morphs that are
>>>>>>> likely
>>>>>>> to end up as a subMorph (saaaay, the TextMorph which I started
>>>>>>> investigating in the first place), as they have to redraw the
>>>>>>> entire
>>>>>>> area anyways.
>>>>>>> This leads to a bad cycle in morph development;
>>>>>>> "As long as at minimum the area we want to redraw is marked as,
>>>>>>> it's
>>>>>>> fine. There's no performance gain from reporting a more accurate
>>>>>>> area
>>>>>>> anyways".
>>>>>>> So you end up with "sloppy" damage rects for new morphs, which
>>>>>>> leads
>>>>>>> to more to fix if it IS changed, and slower performance for
>>>>>>> those
>>>>>>> whom redrawing the entire area rather than a subsection IS
>>>>>>> expensive.
>>>>>>> </rant>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Henry
>>>>>>>
>>>>>>>
>>>>>>> On 27.05.2009 19:44, Stéphane Ducasse wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Thanks for reporting.
>>>>>>>> Henrik?
>>>>>>>> I could rollback the changes.
>>>>>>>>
>>>>>>>> Stef
>>>>>>>>
>>>>>>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Performance of UI seems poor after 832 integration.
>>>>>>>>>
>>>>>>>>> http://code.google.com/p/pharo/issues/detail?id=832
>>>>>>>>>
>>>>>>>>> Regards, Gary
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Pharo-project mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>>>>>> project
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Pharo-project mailing list
>>>>>>>> [hidden email]
>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
> ---
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>> [hidden email]
>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>>>> project
>>>>>>>
>>>>>>>
>>>>>> ----------------------------------------------------------------------
> --
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>> project
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>>
>>>>
>>> 'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009
>>> at 11:39:22 am'!
>>>
>>> !Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'!
>>> drawSubmorphsOn: aCanvas
>>> "Display submorphs back to front"
>>>
>>> | drawBlock |
>>> submorphs isEmpty ifTrue: [^self].
>>> drawBlock := [:canvas | submorphs reverseDo: [:m | canvas
>>> fullDrawMorph: m]].
>>> self clipSubmorphs
>>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>>> ifFalse: [drawBlock value: aCanvas]! !
>>>
>>>
>>> !LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc
>>> 5/3/2006 14:27'!
>>> drawSubmorphsOn: aCanvas
>>> "Display submorphs back to front"
>>>
>>> |drawBlock i|
>>> submorphs isEmpty ifTrue: [^self].
>>> drawBlock := [:canvas |
>>> (self topVisibleRowForCanvas: aCanvas) to: (self
>>> bottomVisibleRowForCanvas: aCanvas) do: [ :row |
>>> i := self item: row.
>>> canvas fullDrawMorph: i]].
>>> self clipSubmorphs
>>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>>> ifFalse: [drawBlock value: aCanvas]! !
>>>
>>>
>>> !PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'!
>>> drawSubmorphsOn: aCanvas
>>> "Display submorphs back to front, but skip my background sketch."
>>>
>>> | drawBlock |
>>> submorphs isEmpty ifTrue: [^self].
>>> drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~
>>> backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]].
>>> self clipSubmorphs
>>> ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock]
>>> ifFalse: [drawBlock value: aCanvas]! !
>>>
>>>
>>> !TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc
>>> 5/31/2007 14:11'!
>>> drawSubmorphsOn: aCanvas
>>> "Display submorphs back to front.
>>> Draw the focus here since we are using inset bounds
>>> for the focus rectangle."
>>>
>>> super drawSubmorphsOn: aCanvas.
>>> self hasKeyboardFocus ifTrue: [
>>> self selectedTab ifNotNilDo: [:t |
>>> self clipSubmorphs
>>> ifTrue: [aCanvas
>>> clipBy: self clippingBounds
>>> during: [:c | t drawKeyboardFocusOn: c]]
>>> ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! !
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Internal Virus Database is out-of-date.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 270.12.11/2089 - Release Date:
> 30/04/2009
> 05:53 p.m.
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Schwab,Wilhelm K

Re: Issue 832 feedback

In reply to this post by Henrik Sperre Johansen

Henry,

I can try by finding when I posted the comment and looking at images from around that time.

How fast do you type? When I am _really_ on, I burst at well over 100 words per minute, which might be asking a bit much from syntax highlighting, etc. But 70 wpm is probably not all that unusual - are you saying the Pharo can keep up with that? My experience is that it falls behind and almost certainly loses keystrokes. How long does it take you to open a browser? How long does it take to recompile a class to change its category? I have to say that Pharo is currently too slow for comfort in those areas for my taste. From things I have seen posted here, I suspect OB is central to a lot of it, and should perhaps be reconsidered as the toolset of choice. One post in particular pointed the finger of blame at OB's design in handling (IIRC) packages, suggested a performance enhancing design change, and as quickly ruled out making it for fear of losing backward compatibility with Squeak.

Bill

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Henrik Johansen [[hidden email]]
Sent: Friday, June 12, 2009 8:29 AM
To: [hidden email]
Subject: Re: [Pharo-project] Issue 832 feedback

The only thing which has been reported:

"Having tried it both ways, the rollback is "a must." There is probably
an argument that the updated image dos a little better with it than does
my 10303 image, but both benefit when the rollback is applied.

Bill"

I see no way to reproduce the slowdown (which I don't experience) from that information.
Care to share some more on exactly what version you are running when noticing/not noticing slowdowns + process that eliminated slowdown for you?

Gary, got any feedback?

There has been no feedback (that I've noticed) about my experience that simply saving the image would eliminate the slowdown experienced after a System... -> Software Update.

Cheers,
Henry

Stéphane Ducasse skrev:

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

123