New Pharo based on core 10318 with antialiased fonts

> What we could do is to upload both quick workaround (the one Nico  
> did for
> the debugger) and the one of creating the method isClassNode which  
> returns
> false. Obviously this is temporal till the real fix arrives. The  
> ticket
> won't be closed.
>
> Then we add a comment in the ticket that says "to reproduce this,  
> remove
> isClassNode method and do a right click on the code ....".
>
> I think this will help Pharo users.
>
> Cheers,
>
> On Wed, May 27, 2009 at 6:36 PM, Adrian Lienhard <[hidden email]>  
> wrote:
>
>> Thanks.
>> No let's hope some OB maintainer picks it up...
>>
>> Adrian
>>
>> On May 27, 2009, at 21:17 , Nicolas Chillo wrote:
>>
>>> Ready.
>>> http://code.google.com/p/pharo/issues/detail?id=849
>>>
>>> Nicolas
>>>
>>> On Wed, May 27, 2009 at 4:10 PM, Adrian Lienhard <[hidden email]>
>>> wrote:
>>>
>>>> Hi Nicolas,
>>>>
>>>> Could you open an issue in the tracker? This would significantly
>>>> decrease the risk that the bug gets forgotten.
>>>>
>>>> Thanks,
>>>> Adrian
>>>>
>>>> On May 27, 2009, at 20:05 , Nicolas Chillo wrote:
>>>>
>>>>> Hi.
>>>>> I recently download the new 10318 development image and it seems  
>>>>> the
>>>>> OBTextSelection>>isClassNode MNU is not fixed yet.
>>>>> (See
>>>>>
>>>>
>> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008782.html)
>>>>> I just want to remind it for you to fix it because it would be a
>>>>> really pity
>>>>> to release a version with such a silly error.
>>>>> Thanks and excellent work.
>>>>> Nicolas
>>>>>
>>>>> On Wed, May 27, 2009 at 12:59 PM, Damien Cassou <
>> [hidden email]
>>>>>> wrote:
>>>>>
>>>>>> On Wed, May 27, 2009 at 3:37 PM, Simon Denier <[hidden email]
>>>>>>>
>>>>>> wrote:
>>>>>>> Yes, installing ECompletionOmniBrowser  before OCompletion
>>>>>>> should do
>>>>>>> the trick.
>>>>>>
>>>>>> Could you please check Romain and tell me so that I can update  
>>>>>> the
>>>>>> script?
>>>>>>
>>>>>> --
>>>>>> Damien Cassou
>>>>>> http://damiencassou.seasidehosting.st
>>>>>>
>>>>>> "Lambdas are relegated to relative obscurity until Java makes  
>>>>>> them
>>>>>> popular by not having them." James Iry
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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

>
>
> Bill
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]
> ] On Behalf Of Stéphane Ducasse
> Sent: Wednesday, May 27, 2009 12:44 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Issue 832
>
> 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
>

> 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

> On Wed, May 27, 2009 at 3:37 PM, Simon Denier  
> <[hidden email]> wrote:
>> Yes, installing ECompletionOmniBrowser  before OCompletion should do
>> the trick.
>
> Could you please check Romain and tell me so that I can update the  
> script?
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> First let me say,  I  love OCompletion, first time I've found  
> completion
> in Smalltalk actually helpful!
> Here's a few things I found a bit of though:
> - Font for OCompletion inherits ECompletion's behaviour of being
> hardcoded (O(X)MenuMorph class >>messageFont/titleFont), would it be
> possible to change them to one of the settable font-preferences?
> (Balloon-help font f.ex.)
> - Suggestions do not seem to be case-sensitive, even if you use
> uppercase in your writing. (writing f.ex. Ope lists open)
> - Words you've fully written are still included in suggestion list.
> (f.ex. open)
> - If a new character excludes items in the suggestion list, they are
> removed, but entries not in the OCompletion cache (but in the extended
> list) are not added to suggestions. - Type in enough characters to  
> make
> the cached suggetions empty, and the extended list becomes  
> unavailiable...
> - If I select to write out the entire message name (say  
> openMenuFor: ),
> then hit space, the entry is not added to top of OCompletion  
> suggestions
> for "open".
> - Two above aren't very annoying, but as far as I can tell, combined
> they mean the only way to add new items to the OCompletion cache is if
> you select it from the extended list.

> 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
>

> 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
>
>
>  

> 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

> 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-proje
>>>>>> ct
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ------
>>>>>
>>>>> _______________________________________________
>>>>> 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

> 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-proje
>>>>>> ct
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ------
>>>>>
>>>>> _______________________________________________
>>>>> 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

> 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

> 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
>
>
>