More UI transparency problems (prolly my fault)

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

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

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