tinchodias wrote > However, I can say the Epicea changes browser is prepared > to this scenario because it delays its UI refresh some milliseconds after > a > change announcement happened.
Can verify this really helps, having loaded large batches in a 6.1 image (with no other browsers open, for obvious reasons...) Though, it would be nice if the UI/change flushing updates were sent by signals to corresponding threads, instead of being forked off each time. That way, they doesn't clutter up a "start profiling all processes" with 5 - 20 ms entries for 999 different processes, so finding other slowdowns is less of a hassle... I assume its done the current way to avoid requiring explicit closing in order to not leak memory (running deferrer process referencing receiver, etc), but that can be avoided using a WeakMessageSend, see attached for example changes: OmDeferrerThreaded.cs <http://forum.world.st/file/n4958297/OmDeferrerThreaded.cs> Cheers, Henry -- View this message in context: http://forum.world.st/Epicea-Revert-the-removal-of-a-class-tp4957466p4958297.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
