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
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project