[Mono-bugs] [Bug 661956] New: Mac: Repainting of PictureBox fails to invalidate overlapping Controls
bugzilla_noreply at novell.com
bugzilla_noreply at novell.com
Fri Dec 31 10:51:04 EST 2010
Summary: Mac: Repainting of PictureBox fails to invalidate
Product: Mono: Class Libraries
OS/Version: Mac OS X 10.5
Priority: P5 - None
AssignedTo: mono-bugs at lists.ximian.com
ReportedBy: c8 at vokabeln.de
QAContact: mono-bugs at lists.ximian.com
Found By: ---
Created an attachment (id=406673)
screenshot of the different behaviour on Windows versus Mac (growing Labels)
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64;
Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729;
Media Center PC 6.0; MDDC; .NET4.0C)
When controls (e.g. Labels) are placed in front of another control (e.g. a
PictureBox), the invalidation and repainting behaviour of Mono differs
significantly between Windows (doing well) and Mac (doing wrong). By
consequence, Mono on Mac fails to repaint controls, e.g. partly "covering" a
TextBox with an orange rectangle which does not belong there.
Please open the attached PNG image to understand the following:
* We have a Windows Form with an orange .BackColor
* On the Form there is a green PictureBox. The .Paint event of this PictureBox
has a special design: It alternately uses LightGreen, Green and DarkGreen color
to paint the PictureBox (or whatever *part* of the PictureBox is being
* In front of the PictureBox, there is a TextBox with just some text on it.
* Also in front of the PictureBox, there are two Labels with yellow .BackColor
and .AutoSize = True. It is essential that one Label is *above* the TextBox,
the other Label *below* the TextBox.
* A Button serves to change the text on the Labels: Depending on the
CheckBoxes, it either adds another "M" to the text, or it removes an "M".
Steps to Reproduce:
Try the attached test VB.NET case (or look at the screenshots) to see what
happens on Windows (using Mono) as opposed to Mac (using Mono):
1. Start the programme.
2. Leave the CheckBoxes checked (i.e. Grow the labels).
3. Click on the Button several times.
As you can see on the screenshots, things on Windows are as they should be: The
text on the Labels is changed, everything else stays the same. Apparently,
Windows handles this quite cleverly, as the PictureBox is never being repainted
(and it needn't be, because the Labels are *growing*).
On Mac, however, every change to the text of the two Labels causes a whole
rectangle of the PictureBox to be repainted (which can be seen thanks to the
different shades of green). That's a little waste of resources (as the
repainting isn't necessary), but basically it's not a problem. BUT:
Unfortunately, the TextBox in the middle is affected by the repainting, too!
The affected parts of the TextBox simply assume the Form.BackColor, thus making
the text illegible. The larger the Labels get, the larger the affected part of
the TextBox gets.
On Windows, the programme works perfectly. Mac, however
* should EITHER be as smart as Windows and not repaint the PictureBox at all
(as the Labels are growing)
* OR it should realize that repainting a whole rectangle of the PictureBox
makes it necessary to repaint the affected parts of the TextBox, too!
Now look at the second set of screenshots: Here, the CheckBoxes are unchecked,
so with each Button click, one "M" is removed from the Labels.
* Windows now smartly repaints only the very bits of the PictureBox that are
now "uncovered" by the missing "M"s.
* Mac again repaints a whole rectangle, again affecting parts of the TextBox,
again "forgetting" to repaint the TextBox!
Variations of the problem:
* The special .Paint event code for the PictureBox is just for purposes of
demonstration, i.e. it is not essential to the problem: Even if the
PictureBox1.Paint event just consists of "e.Graphics.Clear(Color.Green)", the
TextBox will be partly covered with an orange rectangle on Mac.
* The same is true if instead of a PictureBox we use a large Label (.AutoSize =
False, .BackColor = Green) and give it the same Bounds as the PictureBox had.
* But: If a *Panel* is used instead of the PictureBox, then the problem does
NOT occur IF the TextBox and the Labels are part of Panel.Controls (i.e. if in
the Controls hierarchy, they are "children" of the Panel). However, if both the
Panel and the TextBox/Labels are "children" of Form.Controls, the problem again
* Conclusion: On Mac, Mono realizes that when a "parent" Control (such as a
Panel) is repainted, its "children" need repainting, too. However (as shown on
the screenshots), Mono does NOT realize that when painting a Control, there may
be Controls in front of the Control which are *not* "children" of this Control
but nevertheless need repainting.
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.
More information about the mono-bugs