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:* [email protected] > [mailto:[email protected]] *On Behalf Of > *Henrik Sperre Johansen > *Sent:* Wednesday, May 27, 2009 5:07 PM > *To:* [email protected] > *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 >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
