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
