More UI transparency problems (prolly my fault)

[endolf]

Hi
 I've gone back to using my own class that extends UIOverlay and implements UIOveralyInterface. It calls super(width, height, false, true) on construction so the UIOverlay should know that there is transparency envolved. I override the paint method and call something along the lines of

1   2   3   4   5   6   7   8   9

paint(Graphics2D graphics) {   graphics.setBackground(new Color(0,0,0,0));   graphics.clearRect(0,0,width-1, height-1);   graphics.setColor(Color.WHITE);   graphics.drawRect(0,0,width-1, height-1);   graphics.drawString("FPS: " + fps, 2, 2 + graphics.getFontMetrics().getMaxAscent()); }

The problem is that when the first image is rendered it's all fine, then 1 second later I update the fps count with a new frame rate and call repaint, the new image seems to get overlayed on top of the old one, then 1 second later the same happens again, and before long you have a blur of numbers. I've tried creating a buffered image and calling paint(image.getGrahpics()) after I call repaint, but the images dumped from that seem fine (No previous text, just the latest string, and the alpha chanel is correct). I admit that I am lost on this one. Anyone got any ideas? (apart from using opaque fps counter )

Cheers

Endolf

[Jens]

I can confirm this. If you use a translucent background and repaint it several times it becomes black. Very strange.

[endolf]

Hi
 Thanks, at least this means it isn't me, I'll take a hunt round in the UI overlay code tonight, I've not looke at the xith stuff before, but having done my own HUD in java3d, I have a rough idea of whats going on.

The background only goes black because you have the colour of 0,0,0 with some positive alpha, if you use alpha 0 then it never goes black, and if you use say

1	new Color(Color.GREEN.getRed(), Color.GREEN.getGreen(), Color.GREEN.getBlue(), 128);

then it will fade to a vomit green (not that I did a lot of playing with this or anything )

Cheers

Endolf

Games published by our own members! Check 'em out!

[DavidYazel]

This is true.  I have a fix for this and can commit it tonight.

The problem is when the image is relayed from the window's main image and transferred to the sub-image we aere not setting the AlphaComposite to Src, and therefore it is blending with the underlying buffer.

[endolf]

Hi
 Excelent news dave, thanks, because of the time difference I won't get this tonight. but I least I know not to worry about it and I'll try again tomorrow

Cheers

Endolf

[Jens]

Good news that at least one of the bugs gets fixed. I need the fix too.

[endolf]

Hi
 Just seen that david has commited this fix
Thanks

Endolf

[Jens]

Hi
 Just seen that david has commited this fix
Thanks

Did the fix change anything for you? It doesn't work for me (I see no change).

[DavidYazel]

Ah, you need to do the same thing in your code.  Your code is drawing a translucent background on top of itself.  Change your alpha composite to Src, draw your translucent background and then change it back to SrcOver.

[endolf]

Did the fix change anything for you? It doesn't work for me (I see no change).

I'll find out tonight, unfortunatly this nasty 'work' thing is in the way right now, using clearRect worked on the bufferedImages I was dumping to disk (I reused the same image each frame)I think if you are just using fillRect you will need to change teh alpha composite as david suggested.

HTH

Endolf

Games published by our own members! Check 'em out!

[DavidYazel]

Well I know I got past this because I just finished the new translucent chat boxes, so its just a matter of figuring out what I did

[endolf]

Hi
 so does this mean that translucent background colours in swing components work properly now too?

/me runs and hides

Endolf

[DavidYazel]

Is that a seperate problem than what we are discussing?  Basically all the swing components work the same in that they are merged into areas below them if they are non-opaque.  The problem here is than on repaints you are effectively merging on top of the last pass. as long as your "reset" that base image on a repaint you should technically be fine.  Its not UIWindow thing at that point, just a Swing thing.

[endolf]

Hi
 My UIOverlay component works fine now, it's the fps counter in this screenshot.
 The swing problem is show in two others, here is the image as it should be, and is when first shown, but when you click in the text boxes to change anything it goes like this. Are you saying that there is something I need to to do the JPanel that all those swing components are in (Jlabel for the logo, JLabels and JTextFields for the rest) ?

Cheers

Endolf

Edit: I've dumped the buffer in UIWindow and it's correct including alpha values, this confuses me as my own UIOverlays now work fine, puzzling

[Jens]

The issues don't seem to be solved. I have two test cases: A JPanel with a positive alpha value (0.2f) and a color of (0,0,0) gets black when repainting several times (like endolf explained above). The second case is a transparent JTextField. When the text changes the old text is not deleted.

[DavidYazel]

I just commited a fix to UIWindow which should solve this.

Before we render to the buffer I clear it like this:

1   2   3   4   5   6   7

if (blendAlpha) {             Graphics2D g2 = (Graphics2D) g;             g2.setComposite(AlphaComposite.Src);             g.setColor(new Color(0, 0, 0, 0));             g.fillRect(0, 0, width, height);             g2.setComposite(AlphaComposite.SrcOver);         }

[Jens]

The last large userinterface update today (not the UIWindow one) freezes my app after a short irregular time without any error message. It just seems to wait infinitely for something to happen. A simple framecounter still works. A similar example (a textfield which shows which object is currently picked) doesn't work anymore. More specifically it doesn't work if it's updated. The same happens if I use a UIWindow with just a JPanel and some picture on it. Currently I don't have a clue what causes this. I think it's related to the userinterface, because it doesn't happen if I don't use UIWindows. Can anyone else please test this?

[DavidYazel]

hmmm, that isn't good

I did commit a huge bunch of changes and I havn't seen the type of thing you described.  It sounds like seperate problems:

1. Freezes

2. Doesn't update?

The magicosm user interface is pretty big at this point and I am not seeing any issues at all, so this is hard for me to reproduce.

A short test program, or really accurate description would be needed for me to figure this out.

[Jens]

I put a testcase together and found out that everything works fine, if I synchronize every change in the userinterface to the rendering thread. This was a bit harder to track down, because I didn't get an exception. How do you handle updates of the userinterface?

[DavidYazel]

This issue is probably the RepaintManager.  On every frame we check to see if the repaint manager has any marked dirty areas.  If we do then we paint the window to a buffer and transfer the dirty areas to the 3d card.  So if you had 2 threads and one was marking things dirty at the same time we were painting/rendering the component then perhaps somthing bad could happen, but the code was written to support that.  In magicosm we post the events from the canvas to the window manager through a straight adaptor, so it is happening on the swing thread.  We have not had any issues with losing screen updates.

You technically should be able consume your gui events asycnhronously and have the rendering still work fine.  So technically you can call button.setText() anytime from any thread and it should update properly on the next frame.  if you have a test case where this is not the case please let me se eit and I will try to fix it.

[Jens]

I put up a testcase here: http://www.xith.org/tutes/filestore/userinterface_test/

[Jens]

If you run this app it should freeze within some seconds assuming you move your mouse around. It's a simple text field which is updated everytime the mouse moves. The updates work until the app freezes.

[Jens]

Any news about this? Anyone having a freezing app running the testcase above?

[endolf]

Hi
 I'm not having any troubles with my own app now (except that highlighting the content of a text field doesn't change the display, but thats another issue ). I'll have a look at it when I get home tonight (8 hours and counting).

Endolf.

[endolf]

Any news about this? Anyone having a freezing app running the testcase above?

Me

Ok, i got it to lock and did a <ctrl>break and got this log. It looks to me like something funny is happening when the awt thread tries to update the gui whilst it is being rendered by xith, although i'm not sure, I'll spend a little more time looking at it. It might be usefull if we could get a few traces like this to see what threads are where and what is waiting on what. The fact that it just hangs and doesn't crash certainly suggests to me a thread locked somewhere.

Endolf

[endolf]

Ok
 Looking at the code I think you might have suspected that it was to do with calling setText whilst it was rendering. If I comment out the normal setText, and use the scheduled one *only* it works fine. It's the old issue of updating an object whilst it's being rendered. The solution?, don't do it . It seems as though you are fine with mouse click fired events (I certainly seem to be), but i'm not sure if that is just luck or not, but updates that you can schedule easily should be I think.

HTH

Endolf

[Jens]

Ok
 Looking at the code I think you might have suspected that it was to do with calling setText whilst it was rendering. If I comment out the normal setText, and use the scheduled one *only* it works fine.

That's what I wrote some posts above. Actually this is the reason why I have the scheduling code in there.

It's the old issue of updating an object whilst it's being rendered. The solution?, don't do it . It seems as though you are fine with mouse click fired events (I certainly seem to be), but i'm not sure if that is just luck or not, but updates that you can schedule easily should be I think.

I can't fully agree. You don't always have full control of all the events which happen in your GUI, because some events are handled by Swing internally, if the GUI is more complex (sliders, tabbed panes).

[DavidYazel]

I have checked in a fix.  Give it a try.

[Jens]

The testcase above works now, but in another app I get the following message:

1	java.lang.Error: Cannot call invokeAndWait from the event dispatcher thread

The reason is that I perform picking when the mouse moves. The picking method of view calls getRenderFrame(). This again causes this piece of code to be executed:

1   2   3   4   5   6

// if there is a window manager on this canvas then render it UIWindowManager winMgr = canvas.getWindowManager(); if (winMgr != null) {     winMgr.newFrame(getTransform());     renderNode(winMgr); }

Simply put picking doesn't work anymore. Can you confirm this?

[DavidYazel]

hmmm, We can check with Yuri, but I don't think you can saftly call getRenderFrame() while the frame is being drawn.  We can disable the window update during a picking pass though and it would help.