When we added this property to the Canvas and ContainerControl there was probably a lot of head scratching going on. Some of you probably asked yourself (or us) “Why is this necessary?” or “Isn’t this pretty much the same thing as enabling DoubleBuffer?”
Well, yes to the latter question on Windows, and a slightly more optimized experience on OS X, but the impetus behind this property was really our redesigned IDE. More specifically, it was a need/requirement because of a long standing issue with our Linux framework.
The Guts Of The Problem
Those familiar with GTK+2 might know the GdkWindow rendering model, that all transparent widgets do not own a GdkWindow and inherit its parents’. When a control owns its own GdkWindow, however, that control is no longer transparent. Now owning a GdkWindow isn’t significant by itself, but to be a container that knows how to clip its children it has by default a GdkWindow attached. Therefore our dilemma on Linux. We cannot clip child controls on Canvases or ContainerControls if they are transparent. The following screen shot shows the difference between a transparent canvas vs. a non-transparent canvas on Linux. One clips while the other doesn’t.
The Need In The IDE
Our new Inspector pane is a ContainerControl that needed proper clipping. Luckily we had no need for this container to be transparent which allowed us to utilize this new feature and enable clipping on Linux as seen below.
Conclusion
As much as possible we try to normalize behavior across platforms and in most cases it’s a non-issue. However, in this case we were really faced with a problem that didn’t have a sensible framework-only solution. As you can imagine, control sizes on Linux are another source of headaches, especially with all the various themes and window managers dictating the padding and size. However that’s a different topic, and the solution is Auto Layout which Geoff has blogged about recently.