More UI transparency problems (prolly my fault)

Engines, Libraries and Tools Xith3D Forums
#1

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

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 :P)

Cheers

Endolf

#2

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

#3

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

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

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

Cheers

Endolf

#4

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.

#5

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 :slight_smile:

Cheers

Endolf

#6

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

#7

Hi
Just seen that david has commited this fix
Thanks

Endolf

#8

[quote]Hi
Just seen that david has commited this fix
Thanks
[/quote]
Did the fix change anything for you? It doesn’t work for me (I see no change).

#9

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.

#10

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

#11

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 :slight_smile:

#12

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

/me runs and hides

Endolf

#13

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.

#14

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

#15

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.

#16

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

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


    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);
        }
#17

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?

#18

hmmm, that isn’t good :slight_smile:

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.

#19

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?

#20

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.