Skip to main content

jxlayer.jar not signed anymore?

16 replies [Last post]
pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

Today I wanted to update my blog for some SwingX related stuff and also decided to download a fresh jxlayer.jar (I remembered that recently some bug was fixed).

However, it seems that the current jxlayer.jar file (downloaded from the JXLayer project page) is no longer signed.

So I reverted to my previous copy.

If you like to see the TransformUI in combination with SwingX (and JXPanel's RepaintManagerX) have a look here
http://www.pbjar.org/blogs/jxlayer/version_2/

Piet

Added the link

Message was edited by: pietblok

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
alexfromsun
Offline
Joined: 2005-09-05
Points: 0

Hello Piet

The fix I was talking about disables double buffering when a component is painted to an image,
but it happens only when it is painted outside the usual paint() methods routine,
e.g. when you press a button and paint a component in the actionListener

I realized that it was probably not your case

I am not sure how TransformUI painting is implemented
(will have a look when I have a minute)

Swing double buffering can be pretty offensive
http://weblogs.java.net/blog/alexfromsun/archive/2008/04/custom_repaintm...

Thanks
alexp

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

> Swing double buffering can be pretty offensive
> http://weblogs.java.net/blog/alexfromsun/archive/2008/
> 04/custom_repaintm.html

Interesting link. I'll have a closer look at it tomorrow and see if it can help my cause.

Thanks,

Piet

pietblok
Offline
Joined: 2003-07-17
Points: 0

YES,

Thank you Alex for that golden hint. Just setting double buffering enabled to false on the RepaintManager and invoke paint() to render the image. When done, restore to its original value. That does the trick!

It works on all versions of java 6, not only the update N versions.

(I updated the blog and removed the "paint over print option")

Thank you so much.

Piet

alexfromsun
Offline
Joined: 2005-09-05
Points: 0

Hello Piet

Globally disabling double buffering is certainly works,
but it's not the best solution because it affects all the components even if they are not inside JXLayer

Unfortunately there is no easy and good solution

First I would try to disable double buffering for the frame's rootPane,
and check it it helps

If not I am afraid setting double buffering off recursively for all JXLayer subcomponent
is the only correct solution
setLayerMask(AWTEvent.CONTAINER_EVENT_MASK) should help when the hierarchy is unstable

Thanks
alexp

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

Thanks for the comments. There is something that I don't quite understand:

>but it's not the best solution because it affects all the components even if they are not inside JXLayer

This is my current paint code in TransformPort:

[code]
RepaintManager rpm = RepaintManager.currentManager(this);
boolean saveDBE = rpm.isDoubleBufferingEnabled();
try {
rpm.setDoubleBufferingEnabled(false);
view.paint(g3);
} finally {
rpm.setDoubleBufferingEnabled(saveDBE);
}
[/code]

where [b]g3[/b] is the transformed Graphics object of a BufferedImage, and [b]view[/b] is the TransformPort's only child.

Now, how could components not in the view hierarchy be affected? The DoubleBufferingEnabled state is restored after the paint process.

So, when drawing the created image on the original Graphics argument from the paint method of TransformPort, that DoubleBufferingState is the same as upon entry.

Thanks,

Piet

Thanks,

Piet

alexfromsun
Offline
Joined: 2005-09-05
Points: 0

Hello Piet

Unfortunately the first call rpm.setDoubleBufferingEnabled(false) is disabled the gray rect fix,
and the next rpm.setDoubleBufferingEnabled(true) doesn't bring it back.

I mentioned it in the blog entry given in the previous messages.

This made me think how to fix it in the nearest release

Thanks
alexp

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

Thanks. Yesterday night I just glanced through your blog and saw the DoubleBufferedEnabled methods on RepaintManager and went to bed very happy.

This morning I implemented my change without looking again more closely at your blog.

Now ofcourse I want to read it more carefully, but Internet Explorer says that it gets (HTTP 403 Forbidden), so, they advise me to first login. But I am logged in! It says it clearly on the page where I'm typing this message: "Welcome, pietblok".

Well, the feared grey rectangle didn't byte me yet. I'll try again later to visit your blog.

Thanks,

Piet

alexfromsun
Offline
Joined: 2005-09-05
Points: 0

Hello Piet

I suspect you clicked the quoted link which was cut in two lines,
try this one

http://weblogs.java.net/blog/alexfromsun/archive/2008/04/custom_repaintm...

Thanks
alexp

pietblok
Offline
Joined: 2003-07-17
Points: 0

Your suspicion was quite right. :-)

Thanks

Piet

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

Now I've read the blog more carefully and inspected the source code for RepaintManager and BufferStrategyRepaintManager. Yes, I see what you mean.

But, as I understand correctly what's going on, it means that [i]whatever[/i] I do, I will run into the grey rectangle problem, for the simple fact that I [i]need[/i] a custom RepaintManager (to have repaint requests for child components propagated to the TransformPort). And exactly the same goes for SwingX and its JXPanel with alpha settings that require the RepaintManagerX.

In my case, the new paint implementation does not [i]add[/i] a problem. It is already there for the simple fact of my custom RepaintManager.

Talking about RepaintManagers: some time ago, in another thread, you mentioned an up to yet undocumented change in RepaintManager as of java 6u10. That change made it possible to install RepaintManagers for specific components. In the source code I see a private method getDelegate() that asks SwingUtilities3 for a delegate for a specific component. Is that part of the change?

I've looked at this before and I'm not so sure that I'm happy with this feature.

Thinking of the specific purpose of my TransformRepaintManager, propagating the repaint request to a component higher in the hierarchy, the function of my RepaintManager would be spoiled if one of the child components has its own delegate that is unaware of my need. (I'm not sure, but I guess the SwingX RepaintManagerX does something similar as my TransformRepaintManager).

Is my concern clear? and could you comment on it?

Thanks,

Piet

alexfromsun
Offline
Joined: 2005-09-05
Points: 0

Hello Piet

Actually I don't think it is useful to sign jxlayer.jar,
I used a self generated signature just to make it possible to run
webstart demos that use AWTEventListener

Currently none of my jxlayer demos use AWTEventListener
and I stop signing jxlayer because it will reduce
the number of security windows when you run a signed demo

Let me know if signed jxlayer.jar is a must for you

TransformUI is a very cool project, could you give some details
about how you transform the components?

Do you transform an image or you paint a component on transformed graphics?

Thanks
alexp

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

> Currently none of my jxlayer demos use
> AWTEventListener
> and I stop signing jxlayer because it will reduce
> the number of security windows when you run a signed
> demo

I'm not sure, but a security window will only popup if all permissions is asked in the jnlp file, not per se if the jar is signed. Am I wrong here?

> Let me know if signed jxlayer.jar is a must for you

The magnifying glass demo's need it (they are build upon uneditable JTextPanes). If necessary, I can sign your jar with my own signature. But I prefer a jar signed by you.

> TransformUI is a very cool project, could you give
> some details
> about how you transform the components?
>
> Do you transform an image or you paint a component on
> transformed graphics?

Thank you :-)

No, I don't transform an image, because that gives considerable quality loss.

All painting is done on the overridden paint(Graphics g) method in TransformPort. (I think this is the first time that I overrode that method). The strategy is as follows:

1) Create a BufferedImage the size of the clip bounds.
2) Create a Graphics object from the image
3) Transform the Graphics object
4) [b]print[/b] (not paint) the view on that Graphics
5) Draw the image on the argument Graphics

I think I have tried anything to use paint instead of print. A couple of times I thought I was close, but eventually show stopping problems would pop up. I suspect that the buffer strategy plays a role in these problems. But there may be other reasons why it will not work.

Thanks
Piet

alexfromsun
Offline
Joined: 2005-09-05
Points: 0

Hello Piet

Feel free to sign jxlayer.jar with your own signature

painting a component to an offscreen image with paint() methods
can corrupt these components on screen

I fixed this problem in JDK 6u14 b02,
so you are welcome to check if paint() method works well there

https://jdk6.dev.java.net/6uNea.html

If you paint components to the transformed graphics,
have you considered using antialiasing?

the inclined lines look much better with it

Thanks
alexp

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

> Feel free to sign jxlayer.jar with your own
> signature

OK, no problem.

> painting a component to an offscreen image with
> paint() methods
> can corrupt these components on screen

Well, that explains a lot of the problems that I encountered! I even got into situations where corrupted data originating from one window got displayed on another window.

> I fixed this problem in JDK 6u14 b02,
> so you are welcome to check if paint() method works
> well there
>
> https://jdk6.dev.java.net/6uNea.html

I will certainly give it a shot, but that will take some time. If it works, I hope I can query the Java version and, based on the version, decide to use paint or print dynamically.

> If you paint components to the transformed graphics,
> have you considered using antialiasing?
> the inclined lines look much better with it

Yes, there is a method setRenderingHints(map) in the TransformPort. So it is up to the user. (Since actually all transformation and painting is done in the TransformPort (and the Transformer) and the TransformUI is only used for event dispatching, practically everything must be controlled via the TransformPort).

In the Transform demo I actually do use antialiasing. But I'm not overly happy with the resulting quality. I will experiment some more with other hints.

Thanks,

Piet

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

> > I fixed this problem in JDK 6u14 b02,
> > so you are welcome to check if paint() method
> works
> > well there
> >
> > https://jdk6.dev.java.net/6uNea.html
>
> I will certainly give it a shot, but that will take
> some time. If it works, I hope I can query the Java
> version and, based on the version, decide to use
> paint or print dynamically.

Alas, :-( I tried it, but there still are some problems:

1) In the TransformUI demo (with those 16 buttons), the menu bar is overwritten by part of the titled border of the JXLayer. And I can assure you that I only paint first on the image, and draw that image onto the TransformPort.

2) I see a blurred painting on some components. I suspect that this is caused by double buffering in some components of the view hierarchy. Well, that is something that I can understand. The component creates an image of itself and only then draws that image onto the transformed Graphics.

Problem 2 could be solved if there was some possibility to disable double buffering for a complete component hierarchy.

Problem 1 might require some refinement on the fix you applied?

I tested on:

XP Professional SP3
java version "1.6.0_14-ea"
Java(TM) SE Runtime Environment (build 1.6.0_14-ea-b04)
Java HotSpot(TM) Client VM (build 14.0-b13, mixed mode, sharing)

I will add some control button on that Transform demo, to toggle between print and paint. Then you can see for your self what happens.

Deo volente somewhere tomorrow I will update the blog with that toggle button (and some other refinements that I also made). I'll let you know.

Cheers, it's time for my evening glass of wine. I already opened the bottle.

Piet

pietblok
Offline
Joined: 2003-07-17
Points: 0

Hi Alex,

Just updated the blog. http://www.pbjar.org/blogs/jxlayer/version_2/

1) The most recent jxlayer.jar is used, signed by me.

2) Added an option "paint over print" in the options menu for the TransformUI demo (the one with the 16 buttons plus some text components) and the combination of SwingX and the TransformUI (with the rotating busy labels). I added a warning that this option is specifically targeted at you for testing purposes.

3) As usual I restructured the code considerably. Makes me think of many project leaders I worked with who allways told me that "Better is the enemy of Good". Nowadays I am my own project leader. What a relief! For them as well ;-)

Piet