Time for black magic: overlapping siblings. They are always a big trouble:
1. NSView's documentation (obsolete?) says sibling views should never overlap. Fortunately,
   this is not true (or I'm lucky till now). Looks like Cocoa can draw them in a correct order, so this is not a problem.
   The problem is ROOT - GUI classes can draw outside of paint event.
2. View is not a window, there is only one real top-level window for each main frame and there is 
   only one backing store (or something like this) per top-level window. And there is one graphics context
   for this window. So, if ROOT's GUI decides to draw at some point, when IT'S NOT ASKED TO DRAW,
   it will draw into this backing store, ignoring the fact, that somebody else can overlap this area.

   Fortunately, such cases are very rare. But I can see them, at least with tabs and mdi windows.

To emulate "backing store" for every view, I'm using a clipping - this works for overlapping siblings:
if view's area partially overlapped by one of its siblings or siblings of one of its ancestors (so can
be any number of overlaps in any complex way) - I'm calculating pixel mask for a view, checking ancestors and siblings, if they
overlap with our view and set this mask on a context.

This, sure, does not make anything faster. Fortunately, "draw outside of paint event" happens with quite simple
parts of GUI (like pressed button or highlihgted menu), hierarchies are not terribly deep and widgets are not 
huge (== not to much data to set in a clip mask's array). Tested on overlapping mdi windows from mditest.C, (which have, for example, nested controls like buttons
and comboboxes (which can draw themselves on mouse events, for example).

State of art :)))))


git-svn-id: https://root.cern.ch/svn/root/trunk@44298 27541ba8-7e3a-0410-8455-c3a389f83636
Delete initial version of overlap finder.


git-svn-id: https://root.cern.ch/svn/root/trunk@44299 27541ba8-7e3a-0410-8455-c3a389f83636
Tiny fix in an Warning message.


git-svn-id: https://root.cern.ch/svn/root/trunk@44300 27541ba8-7e3a-0410-8455-c3a389f83636
Apply the patch suggested here:
https://savannah.cern.ch/bugs/?94807

With option COL TProfile2D histograms are handled differently because, for this type of 2D
histograms, it is possible to know if an empty bin has been filled or not. So even
if all the bins' contents are positive some empty bins might be painted. And vice versa,
if some bins have a negative content some empty bins might be not painted.


git-svn-id: https://root.cern.ch/svn/root/trunk@44301 27541ba8-7e3a-0410-8455-c3a389f83636
THistPainter.


git-svn-id: https://root.cern.ch/svn/root/trunk@44302 27541ba8-7e3a-0410-8455-c3a389f83636
Quite funny and subtle bug, I found by accident, when playing with TAttFill editor:
in a color selector you can press "Other..." button, it'll open color select dialog.
Before dialog opens, color selector is unmapped (window becomes invisible), but later
color dialog becomes a transient window for a color selector - as I did not check this,
making one window a transient window for another window also makes this window visible again -
I could see this when closing colors dialog (for several milliseconds color selector's window still was visible).


git-svn-id: https://root.cern.ch/svn/root/trunk@44303 27541ba8-7e3a-0410-8455-c3a389f83636