[mcclim-devel] performance of incremental redisplay

[Timothy Moore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Strandh wrote:
> The slowness of my example from the other day seems to be caused by
> the fact that each top-level output record (of which there are 1000 in
> my example) is moved individually, and moving an output record
> triggers a call to recompute-extent-for-changed-child.  The parent
> then scans all the children to compute the new bounding rectangle,
> resulting in quadratic behavior.
> 
> The solution to this problem seems to be to realize that incremental
> redisplay must traverse all the output records anyway (to see what has
> changed), and so it would be a better idea to put off the computation
> of the bounding rectangle until the end of this entire process. 
> 
> I maintain my previous analysis that it would be a better idea to
> store relative positions in output records, so that moving an output
> record does not require traversing its children. 

It's interesting to note that early versions of CLIM did store the child
positions as relative coordinates; it was considered an important
optimization to move to fixed coordinates! :) I believe that relative
coordinates were identified as a bottleneck in the comparison part of
updating-output.

Trade-offs that were important 20 years ago may not be relevant today...

Tim

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFmhqeeDhWHdXrDRURAu1TAJwIycuUZcSGOmzf6fn/TEtfSqSuZwCgiIUS
eylxeKojeo3bIph3ZU6GXeY=
=2drZ
-----END PGP SIGNATURE-----