Skip to main content

JXPanel V1.6.5 breaks compatibility

13 replies [Last post]
wzberger
Offline
Joined: 2004-08-31
Points: 0

Since V1.6.5 panels look different with Synth based look and feel. The problem seems to be that JPanel#paintComponent() isn't called any longer. Please note in Synth painters are called in the PanelUI#update() method - so not calling super.paintComponent() breaks compatibility.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08
Points: 0

Fix in progress. Hope to update soon.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

[Copy] forum didn't take a new thread

This is loosely related to the painting glitches reported recently, but slightly different - I think the overall behaviour is not yet quite correct (much better than core but still :-)

We have different aspects

- setOpaque (note: the setter!): true or false decides whether a background color is painted at all
- alpha value of the background color
- alpha value of the container hierarchy starting at and below the panel
- painters

Those should be orthogonal to each other, that is configuring one should not effect the others. F.i. deciding to not fill the background should be respected by container-alpha (currently doesn't, always paints) or the other way round deciding to fill should produce no artefacts if the background is (semi-) transparent (currently produces the artefacts).

We know that core can't handle semi-transparent backgrounds due to a catch-22:

- the background is filled only if isOpaque (note: the getter)
- reporting isOpaque == true for not fully opaque colors is illegal, doing so will produce the artefacts

We also know that the reason is an unfortunate design decision to overload the role of opacity: its original role war for internal painting optimization, Swing changed that to allow kind-of configuration of whether or not the background is painted.

A tentative solution might boil down to accept the different semantics of setter vs. getter of the opaque property:

- the setter expresses developers' intention (paint or not)
- the getter must comply to its technical contract

In terms of implementation of JXPanel that would translate to the following changes:

- in setXX (with XX any of the bullets at the top) do not invoke any of the other setYY
- related to opacity, override the getter (instead of the setter)
- in paintComponent, use the user's decision about filling or not the background

Below is some patch code (trying to check in but having strange problems with java.net). It's idea is to not interfere with the current handling if the patch marker isn't set, that is all relevant methods XX ( with XX =setAlpha, setOpaque, isOpaque, paintComponent) start with

      if (isPatch()) {
            XXPatch(...);
            return;
      }

It's sole purpose is to easily play with options and compare the outcome against the normal behaviour, f.i. by setting or not the patch property very early in JXPanelVisualCheck. So beware: it doesn't solve all problems, it demonstrates what I think should be near the optimal behaviour - could be wrong in any aspect :-)

A comparison of 165 vs. patch is (maybe, java net is quirky today) available at

http://swingx.java.net/api-reviews/JXPanel/JXPanel_painting.html

//--------------------- experimental patch
   
    protected boolean isPatch() {
        return Boolean.TRUE.equals(UIManager.get("JXPanel.patch"));
    }

    boolean fakeTransparent;
   
    protected void paintComponentPatch(Graphics g) {
        Graphics2D g2 = (Graphics2D) g.create();
       
        try {
            if (isPaintingBackground()) {
                g2.setColor(getBackground());
                g2.fillRect(0, 0, getWidth(), getHeight());
            }
            if (getBackgroundPainter() != null) {
                getBackgroundPainter().paint(g2, this, getWidth(), getHeight());
            }
            fakeTransparent = true;
            getUI().update(g2, this);
        } finally {
            g2.dispose();
            fakeTransparent = false;
        }
       
    }
   
    protected boolean isOpaquePatch() {
        if (fakeTransparent) return false;
        if (isPaintingBackground()) {
            return !isTransparentBackground() && !isAlpha();
        }
        return false;
    }

    protected void setOpaquePatch(boolean opaque) {
        super.setOpaque(opaque);
    }
    /**
     * Returns whether or not the container hierarchy below is
     * transparent.
     *
     * @return
     */
    protected boolean isAlpha() {
        // PENDING JW: use effective alpha?
        return getAlpha() < 1.0f;
    }

    /**
     * Returns whether or not the background is transparent.
     *
     * @return
     */
    protected boolean isTransparentBackground() {
        return getBackground().getAlpha() < 255;
    }

    /**
     * Returns whether or not the background should be painted.
     *
     * @return
     */
    protected boolean isPaintingBackground() {
        return super.isOpaque();
    }
   
kschaefe
Offline
Joined: 2006-06-08
Points: 0

A few things:
1. This inverts Wolfgang's problem and is susceptible to the opposite issue. The UI delegate might overpaint the background painter. Furthermore, painting background, the bg painter, the UI delegate is incorrect. The UI delegate might not respect the background color if it is a UIResource, so painting it unilaterally is incorrect.
2. The code is not properly configured for respecting the BackgroundPaintable contract.

I recommend trying to address this in the next full release, not trying to wedge it into this quick patch.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

beware: reopened http://java.net/jira/browse/SWINGX-1514 which basically makes setExtendsComponentOpacity of WrappingProvider/IconPanel ineffective (background always extended to the icon) for Nimbus/synth-based lafs - probably the same underlying issue.

Cheers
Jeanette

kleopatra
Offline
Joined: 2003-06-11
Points: 0

filed a blocking issue:

http://java.net/jira/browse/SWINGX-1545

Would be great if you could attach some code snippet that demonstrates the problem.

Thanks
Jeanette

martinm1000
Offline
Joined: 2003-06-12
Points: 0

Hi Jeanette,

I'm glad to see that this project still release versions !
I guess there are some issues that need fixing for the official release of 1.6.5 ? Is there a changelog ? Will your new calendar UI make it ?

kleopatra
Offline
Joined: 2003-06-11
Points: 0

this _is_ the official release of 1.6.5 ;-)

With those glaring painting issues (cough ... ), it'll probably be reasonable to throw out a mere bug-fix release asap (@Karl, what do you think?) after they will be fixed.

It's not entirely trivial, though, especially not as we have a rather poisonous mixture


- jdk 6 -> jdk 7 with changes in the overall painting mechanism related to semi-transparent colors
- heavily buggy (to the extend that we tend to ignore Synth altogether) Nimbus which are highly version dependent
- swingx painters vs. core painters
- bug-introducing individuals like myself ;-)

We did discuss some issues over in the tracker, but obviously decided to take the one or other suboptimal turn. So we definitely need input to get it better next time around.

No changelog, but the tracker has a list of fixed issues (which should be a complete list of changes, in an ideal world)

The calendar ui is on ice, I'm reluctant to finalize it for the old calendar api with jsr310 on its way for inclusion in jdk8 (though didn't do much on that version as well - more interested to get the tree/table sorting ready for release)

Glad that we still have users :-)
Jeanette

martinm1000
Offline
Joined: 2003-06-12
Points: 0

Is there painting issues if I don't use Synth/Nimbus ?
I could try updating my app to see if anything broke...

For your Calendar UI, you could finalize it using joda-time, since its going to be mostly the same API ;-)

Oh you still have users, the proof is the bugs reported after releasing a new version ;-)

Thank you all for your work.

kleopatra
Offline
Joined: 2003-06-11
Points: 0

JRendererCheckBox is broken in all LAFs [edit: that install the checkbox' opacity to false] (entirely due to my stupidity ;-). A quick fix is to set its opacity to true, see the other thread:

http://www.java.net/forum/topic/javadesktop/java-desktop-technologies/sw...

Other than that, the JXPanel seems to be fine - better than before, as the current approach solves some older painting issues - in all core LAFs except synth-based.

Cheers
Jeanette

kschaefe
Offline
Joined: 2006-06-08
Points: 0

To my knowledge there is no problem with non-Synth based, JDK look and feels.

Test away and let us know if you reveal any new issues.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Hi Karl,

middle of the night here - and you beat me by 2min :-)

Cheers
Jeanette

martinm1000
Offline
Joined: 2003-06-12
Points: 0

Ok, well I will need to find more time to test, but a 2 minute tests seems to be ok... but I did saw something bizarre I must investigate... when I double-click my app to maximize it / normal size I see some flickering and a possible repaint in my treetable... And I do not have that problem with the previous swingx...

A Changelog to know where to look might help...

I'll test some more later...

martinm1000
Offline
Joined: 2003-06-12
Points: 0

Ok, this looks like it might have been a false alarm... not sure why... anyway, I would really like a changelog ;-)