Don't toolkits using many (sub-)windows hurt composite?

[Glynn Clements]

Clemens Eisserer wrote:

> Are there special techniques to avoid this problem. Are there any
> recommandations how toolkits should be designed nowdays?

One issue to bear in mind with toolkits which only create top-level
windows is that, if you want enter/leave events on child widgets, you
have to unconditionally enable MotionNotify events on the top-level
window, which is bad news if you are using X remotely over a slow or
congested connection.

[If you want to draw the buttons yourself, you can still create
InputOnly windows to get genuine enter/leave events. The problems with
no-subwindows toolkits are normally due to laziness, i.e. wanting to
write as little platform-specific code as possible, in spite of the
significant architectural differences between X and e.g. MS-Windows.]

While I haven't really looked into compositing, one thing which would
definitely be a bad idea in terms of memory consumption would be
buffering the contents of scrolled windows (the child, not the
viewport). This is easy enough to detect (child larger than parent),
although I have no idea whether existing compositing implementations
actually do so.

-- 
Glynn Clements <glynn at gclements.plus.com>