[SWINGX-1547] JXPanel: define painting behaviour Created: 27/Feb/13  Updated: 27/Feb/13

Status: Open
Project: swingx
Component/s: Misc Component
Affects Version/s: None
Fix Version/s: 1.6.6

Type: Task Priority: Major
Reporter: kleopatra Assignee: Karl Schaefer
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Issue Links:
is related to SWINGX-1518 JXPanel: umbrella issue for paint pro... Closed
SWINGX-1548 JXPanel: SwingX-painter vs. LAF-provi... Sub-task Open Karl Schaefer  
SWINGX-1549 JXPanel: (semi-) transparent backgrou... Sub-task Open Karl Schaefer  
Tags: JXPanel, painting


In the recent discussions (following the regression in 1.6.5) it turned out that the painting behaviour isn't fully defined which leads to differing expectations.

So starting this as a task to

  • define the contracts/behaviour
  • implement as defined

It's an umbrella for several aspects, covered in separate sub-tasks. Ideally, there'll be animated discussions with many participants about all aspects, either in the tasks or in the forum, best with visual examples of what/how/not is painted (slightly hampered by no longer being able to attach anything to jira issues - when did that change?)

Below are some aspects (edit/add as appropriate)

Paint layer, from lowest to highest:

  • background color
  • background painter (swingx and/or core/laf provided)
  • foreground (== content painted by laf)


  • container alpha property
  • background color alpha channel


  • contract of isOpaque
  • developer's intention

The developer should have full control of what is painted. The system should take over all the heavy lifting and automatically take care of not violating contracts.

Comment by kleopatra [ 27/Feb/13 ]

tackling the new tasks must not break the fixes of the older issues

[SWINGX-1534] Weird behaviour of existing applications Created: 17/Nov/12  Updated: 28/Nov/12  Resolved: 19/Nov/12

Status: Closed
Project: swingx
Component/s: Painter
Affects Version/s: None
Fix Version/s: 1.6.5

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

Tags: jxpanel, painting


when run against current swingx.

showing up f.i. in the demos:

  • hangs on startup before text-slidein: intro-image is showing, but looks cloudy, app doesn't react at all to any input event, must be hard-killed
  • running the painter-demo as stand-alone (need to comment the application context injection), showing artefacts when changing the painter: f.i. choose imagePainter/bigPainter, than any other: the new is painted on top of the image, plus some of the "surroundings" (f.i. the tree chooser) - only resizing helps to get rid off those

Didn't dig further, just guessing that it might be related to the recent fixes in the painting logic? If not, will look into earlier commits (lazy me

Comment by Karl Schaefer [ 19/Nov/12 ]

Painters do not necessary fill the entire clip. RepaintManager reuses the same backing buffer. If the client does not clean the clip, then visual artifacts can show through.

This will be a simple change to SwingXUtilities.paintBackground.

Comment by Karl Schaefer [ 19/Nov/12 ]

SWINGX-1534: Ensure that we paint the background behind the painter, when the component is requires background painting (such as when it is opaque). This prevents visual arfifacts from sneaking in because painters may not cover the entire clip.


Committed revision 4262.

Comment by kleopatra [ 20/Nov/12 ]

that was quick, thanks

Fixes the artefact, but not the initial hanging. Any ideas on that?

Comment by Karl Schaefer [ 20/Nov/12 ]

I tested it with the stuff in the swingx repo and there are no issues. Perhaps some change between that and the one in the demos has caused it? I don't keep up with that one.

Comment by kleopatra [ 21/Nov/12 ]

Well, swinglabs-demos is still our reference real-world application - that breaking shows us how existing code will break on changes

So, the other way round: any implicit changes in the swingx rep that might break the real-world stuff? Couldn't see anything obvious ..

Comment by kleopatra [ 21/Nov/12 ]

got it: hangs if run with jdk7, okay if run with jdk6 (both demos project and swingx rep)

Happens somewhere around animating the alpha property in DemoXPanel.

Comment by Karl Schaefer [ 27/Nov/12 ]

SWINGX-1534: Fix isPaintingOrigin. Only need to return true if we should repaint; RepaintManager will do the right thing and find the highest component that should be repainted and go with it.


Committed revision 4264.

Comment by kleopatra [ 28/Nov/12 ]

confirm fix of both bullets

Thanks for the quick work

Generated at Sat Aug 01 09:50:18 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.