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.
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
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.
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);
}
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?
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:
-
Freezes
-
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.
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?
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.
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.
Any news about this? Anyone having a freezing app running the testcase above?
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.
[quote]Any news about this? Anyone having a freezing app running the testcase above?
[/quote]
Me
Ok, i got it to lock and did a 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
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
[quote]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.
[/quote]
That’s what I wrote some posts above. 
Actually this is the reason why I have the scheduling code in there.
[quote]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.
[/quote]
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).
I have checked in a fix. Give it a try.
The testcase above works now, but in another app I get the following message:
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:
// 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?
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.
Agree, no need to change anything. Ignore the post above. ;D Works fine now. The transparency stuff works fine now, too. Thanks for your work on the userinterface.
Are there other possibilites for writing a simple text at an x-y-position on the screen or drawing an image at an x-y-position than using the userinterface? It’s a bit overhead for these simple things. Besides this it also causes problems with events (explanation).
OK, I was watching this thread and periodically testing for possible regressions - good news there are no regressions related to changes in UI [at least no obvious ones].
I can confirm that this is not a good idea to call getRenderFrame() while another frame being rendered, because of it may [MAY] cause race conditions related to atom caching and state sorting/management.
As of pbs related to picking, I double-checked this functionality again and it seems to work as expected.
Yuri