|<< Back to previous view|
[SWINGX-1515] JXPanel: painting artefacts in overlapping frames Created: 08/Aug/12 Updated: 10/Aug/12 Resolved: 08/Aug/12
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Participants:||Karl Schaefer and kleopatra|
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
|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:
The fixes one big hole:
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
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.