What is the cost of WS_CLIPSIBLINGS if the sibling windows don’t overlap?


Commenter Robert May asks via the Suggestion Box whether there is a penalty to pay for using WS_CLIP­SIBLINGS when the sibling windows are not overlapping.

When you use the WS_CLIP­SIBLINGS style, the window manager clips out the portion of the client rectangle that is covered by sibling windows. This is usually desirable behavior; otherwise you end up with two windows trying to paint at the same location, and somebody is likely to get hurt. (The One notable exception is in dialog boxes, where some controls like the group box were designed to have other controls drawn on top of them.)

The cost of this flag is that when it comes time to calculate the visible region for a window, the space occupied by sibling windows higher in the z-order are clipped out. This happens even if the sibling windows don't overlap; after all, the only way to find out whether there are any overlapping sibling windows is to enumerate the sibling windows looking for them! Of course, if there is in fact no overlapping, then the calculations are trivial. The only cost was the loop which determines that there are no applicable siblings to be clipped out.

Comments (20)
  1. configurator says:

    "(The notable exception is in dialog boxes, where some controls like the group box were designed to have other controls drawn on top of them.)"

    This doesn't happen in other windows?

    [It happens, but it is rarely the design intention. I've changed "the" to "one" just to play it safe. -Raymond]
  2. configurator says:

    This makes a bit more sense now. (I've never actually heard of WS_CLIPSIBLINGS as I'm not a Win32 programmer)

  3. Alexandre Grigoriev says:

    Some time ago Larry Osterman wrote about fixing a flickering Vista/7 volume control: blogs.msdn.com/…/building-a-flicker-free-volume-control.aspx

    Ultimately he went through the pain of writing his own groupbox.

    In the comments to that post I suggested: 1) add CLIPSIBLINGS+CLIPCHILDREN to the styles; 2) make sure the group boxes are low in Z-order; and 3) use BeginDeferWindowPos/EndDeferWindowPos.

    Do you think that would help? This worked for me in my projects.

    [Putting the group boxes low in the Z-order breaks keyboard shortcuts. -Raymond]
  4. asf says:

    I always liked the way Borlad VCL groupboxes are actually the parent of its controls (This is more work in plain win32 since you have to forward messages and GetDlgItem etc is problematic in the dlgproc)

  5. jon says:

    Apart from the cost of the enumeration, assuming there ARE overlapping child windows, is there a cost of the resulting extra complexity of the clipping region?

    And I guess the most relevant question is, on modern hardware, are any of these "costs" actually noticeable?

    [The cost is, of course, doing the clipping calculations. Whether this is measureable is left for you to determine. -Raymond]
  6. jon says:

    I wonder what the point of this whole post is. Sounds to me like you don't actually know the answer to the original question. The "cost" is measured in time/performance. It's like if someone asked you "how much do bananas cost" and you answered "they cost their price per pound multiplied by how many pounds you buy").

    [If you're looking for cost in terms of time, then I cannot tell you the answer since it depends on your specific machine configuration. It'll take longer on a P90 than on a P6 Xeon. It's as if the question were "How long does it take me to count to a thousand?" -Raymond]
  7. Scott says:

    The original question was "is there any penalty".  The answer could have just been "Yes".

  8. Scott says:

    The original question was "is there any penalty".  The answer could have just been "Yes".

  9. Alexandre Grigoriev says:

    [Putting the group boxes low in the Z-order breaks keyboard shortcuts. -Raymond]

    I don't quite remember such artifact. In what case it would break the shortcuts?

    Oh, and if you want control-specific tooltips, you better *have* groupboxes low in Z order. Or your ChildWindowFromPoint will always return the box instead of one of included buttons. I suspect this will also be required for accessibility.

    [Press the keyboard shortcut for the groupbox and see where focus goes. And for hit-testing, see RealChildWindowFromPoint. -Raymond]
  10. Alexandre Grigoriev says:

    [Press the keyboard shortcut for the groupbox and see where focus goes. And for hit-testing, see RealChildWindowFromPoint. -Raymond]

    Before I can cobble a test app, I refreshed my memory.

    Pressing a keyboard shortcut causes the selected control or the next in Tab-order to get focus.

    The tab order follows the order in what the controls are created. In Z-order, the first one created is below all others, and the last one created is on top of others.

    This means, if the inner controls of a groupbox are listed immediately after it in the dialog template, they are *above* it in Z-order, and *follow* it in tab order. This also means GetNextDlgTabItem seems to use some equivalent of GetNextWindow(GW_HWNDPREV) for a next child control in tab order.

  11. Anonymous says:

    Not trying to be negative or anything, but this entry seems like something of a non-statement, and one that the questioner could have guessed.  "Is there a cost of looping through sibling windows?  Why yes, it's the cost of enumerating and looping through sibling windows…"  But then, I suppose if there *was* an observable performance hit that actually makes a difference in the questioner's program, then they wouldn't have to ask the question, because the hit would be exactly that: observable.

    [Then I guess I didn't understand the question. -Raymond]
  12. Drak says:

    Don't all be so negative people.

    If you've read Raymonds post carefully you may have learned something from it.

    The cost of using the flag is low, and predictable. No weird stuff happening if windows do not overlap. I find this interesting.

  13. rs says:

    And I guess the most relevant question is, on modern hardware, are any of these "costs" actually noticeable?

    Presumably, it isn't noticable unless you have thousands of windows with weird clipping regions. Anyway, if you do not clip the siblings, you may end up with more extensive drawing operations, which would probably involve a higher "cost".

  14. rs says:

    And I guess the most relevant question is, on modern hardware, are any of these "costs" actually noticeable?

    Presumably, it isn't noticable unless you have thousands of windows with weird clipping regions. Anyway, if you do not clip the siblings, you may end up with more extensive drawing operations, which would probably involve a higher "cost".

  15. Stefan says:

    As I read it you can make the following statements about the WS_CLIPSIBLINGS flag:

    1) Yes, there may be a penalty. You get nothing for free.

    2) Just enumerating the sibling windows and see if they are overlapping is trivial.

    3) Finally computing the overlapped rectangle isn't that hard but is has to be done.

    4) If you are in doubt that your application gets any benefits from clipping out sibling windows you have to make some tests.

    The answer to the question for the costs of the WS_CLIPSIBLINGS flag is a clear maybe. It depends on your application. If you have ever written the code for determining overlapped rectangles you get an idea of the costs. My experience says yes its worth clipping sibling windows.

  16. Alexandre Grigoriev says:

    [Press the keyboard shortcut for the groupbox and see where focus goes.]

    Reporting on the test: all works as expected.

  17. Alexandre Grigoriev says:

    Now back to WS_CLIBSIBLINGS cost. If cost of calculating the clipping region were any significant, it could be reduced to trivial by precomputing all clipping regions in advance, and only updating that on child window move/resize.

    Thus, it's not worth considering, especially in this age of frigaherz processors.

  18. Ens says:

    @Scott:

    Answering "yes" would be one of those answers that is both absolutely true and completely useless.  Explaining that the cost is low and the sort of computation that's happening is far more likely to answer the actual intended question.

  19. gfx freak says:

    Using Aero, does the clipping logic run as shader on the graphic card?

  20. gfx freak says:

    Using Aero, does the clipping logic run as a shader on the graphic card?

Comments are closed.