<< Back to previous view

[SWINGX-1515] JXPanel: painting artefacts in overlapping frames Created: 08/Aug/12  Updated: 10/Aug/12  Resolved: 08/Aug/12

Status: Resolved
Project: swingx
Component/s: Misc Component
Affects Version/s: 1.6.4
Fix Version/s: 1.6.5

Type: Bug Priority: Blocker
Reporter: kleopatra Assignee: Karl Schaefer
Resolution: Duplicate Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: PNG File alpha-xpanelbug.png    
Issue Links:
blocks SWINGX-1518 JXPanel: umbrella issue for paint pro... Closed
duplicates SWINGX-1336 Flickering in JXPanel with alpha < 1 Resolved
Participants: Karl Schaefer and kleopatra


See JXPanelVisualCheck.xPanelInFrame

  • If the upper frame contains a JXPanel with alpha, the lower background is painted
  • only below the area of the upper frame.
  • All fine without alpha on the upper.
  • The exact outcome is erractic (sometimes half or even fully painted).
  • On/off EDT doesn't seem to make a difference.

Test is against current head, that is revision #4225

Comment by kleopatra [ 08/Aug/12 10:56 AM ]

screenshot of the bug (finally found how-to attach from mylyn, cool
The background of the frame in the background should be red

Comment by Karl Schaefer [ 08/Aug/12 12:11 PM ]

Part of the known set of issues when you have an alpha transparency.

Comment by kleopatra [ 08/Aug/12 01:38 PM ]

guilty of not looking for duplicates (though .. that doesn't appear like related to this, but then, I know that transparency handling is not trivial

Shooting a lay-woman (as far as the intricacies of painting goes) question: if using a delegating repaintManager is such a pain, why do we need it? Naively commenting its install in JXPanel doesn't seem to have any obvious effect on first sight (except getting rid of the artefacts). Any example of the evils that happen without?


Comment by Karl Schaefer [ 09/Aug/12 07:02 PM ]

We need something that allows JXPanel to know its child is being repainted so that we can repaint it instead, if the JXPanel is not fully opaque.

I prefer the idea is using the InputEventDispatcher to do this, which avoid RepaintManager tricks. I had thought we'd want to do this after we make that code available, but I can sneak package-private code in instead. It will fail to repaint in the same way the InputEventDispatcher will fails to dispatch...on non-editable JXTextComponents. I think that trade off is much better. When we finally rebase to Java 7, these troubles are supposed to go away.

Comment by kleopatra [ 10/Aug/12 09:46 AM ]

thanks - but still not quite clear (lame excuse: Friday after a long week : why do we have to care? The panel reports to be non-opaque, so the normal manager should be able to handle child repaint requests? Obviously missing some important point somewhere .. do you have a code snippet which demonstrates the problem?


BTW: this particular artefact variant seems to be machine dependent (and/or maybe jdk) - see it on a vista box with 6u27, not on another win7 one, with a slightly younger jdk ... Fine for 7 on both. Sigh ..

Comment by Karl Schaefer [ 10/Aug/12 01:53 PM ]

ReapintManager will not paint the JXPanel if it is covered in non-opaque components. This can cause situations where the JXPanel with alpha transparency is the parent of a button. If the button if repainted, such as on rollover, RepaintManager will not normally repaint the JXPanel because the button is opaque.

See JXpanelVisualCheck.interactiveAlphaCheck. Comment out JXPanel.installRepaintManager in your local copy to see the difference.

Comment by kleopatra [ 10/Aug/12 02:35 PM ]

ahh ... see it, thanks

How does a InputEventDispatcher would help to solve this (can't find the experimental code you mentioned in the other issue .. )

Comment by Karl Schaefer [ 10/Aug/12 02:59 PM ]

It solves the problem by induction. It assumes that if there has been an InputEvent on my descendent, since the events always pass through the parent's InputContext, I should repaint.

This leaves a few holes:
1. Components that do not use InputContexts, such as non-editable JTextComponents, will not allow JXPanel it inspect events, so repaints on that will not force JXPanel repaints.
2. External repaints that are not triggered by InputEvents are not captured.

The fixes one big hole:
1. It doesn't use a custom RepaintManager. Custom RepaintManagers can never use the best painting methods and once set the RepaintManager uses the degraded painting code even if the custom RepaintManager is unset.

In lieu of a InputContext subclass, we could use an AWTEventListener, but those require permissions. It would allow us to listen for PaintEvents directly, which avoids the RepaintManager issues and is more robust than the InputContext approach.

I have overridden isPaintingOrigin, so that Java 7 JXPanels can take advantage of the new code, but we still need some workaround in Java 6. One or more of the above approaches (plus anything else you might think of) needs to be in JXPanel for now. I really like the AWTEventListener idea, but hate AWTEVentListeners. We could support multiple approaches for JXPanel, but I don't really want to support a lot of code that we hope, one day, to remove.

Comment by kleopatra [ 10/Aug/12 05:05 PM ]

thanks for the detailed description

I fully agree with not adding too much code that's no longer needed in jdk7 - wasn't aware that there's a clean solution in that case. If I understand you correctly, we can take advantage of that already by

  • add the method isPaintingOrigin (when compiling with jdk6, that's just a method, not an override) to JXPanel and let it return true
  • not do any of the not-so-cool workarounds (currently: not install the custom RepaintManagerX) if jdk7 is detected at runtime

With EOL of jdk6 so near, maybe we should just shrug shoulders?

Comment by Karl Schaefer [ 10/Aug/12 05:44 PM ]

isPaintingOrigin is the code that was put in place for JLayer to make it work correctly.

Your description about covers it, except that isPaintingOrigin needs a little more complexity than just returning true.

We'll leave the bug for the alpha flickering and other wonkiness open and resolve when we migrate to Java 7.

Generated at Sun Apr 20 02:08:35 UTC 2014 using JIRA 4.0.2#472.