Skip to main content

need heavyweight equivalent of the JInternalFrame control

5 replies [Last post]
brian101
Offline
Joined: 2010-03-22

Are there any plans in the works to add a heavyweight equivalent of the JInternalFrame control to Swing? The lightweight control is causing me lots of issues when rendering multiple, partially overlapping windows.

Here is my situation. I have a lot of windows whose graphics content takes a long time to render. To compensate for this I render them on a buffer in the background so if the user changes their mind or sees something that needs to be adjusted they don't have to wait until all the windows have been drawn. The PaintComponent() simply starts these threads that do the work in the background and returns.

Each thread that is drawing also has it's own timer thread and every so often it wakes up, does an InvokeLater() to copy the current buffer contents to the screen and then goes back to sleep

All this works fine as long as the windows don't overlap. I have even computed my own clipping based on the overlapping windows and their parent windows etc. and verified that this is all giving the correct clips etc. But no matter what, drawing to the lower z order windows (underneath), causes new PaintComponent() messages to be fired for other sibling windows (other JInternalFrames in the same container as the one being rendered).

Anyway after doing considerable research on this I know that this is what I need and there has been talk about providing this but I can't find a definitive answer as to whether it will be provided or, if it is, then when.

thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
anthony_p
Offline
Joined: 2006-07-24

Hi Brian,

Could you please provide the very shortest (and complete - with import statements, etc.) test case that demonstrates the problem? Thanks in advance.

PS. Please use the [ code ] and [ /code ] tags (w/o spaces, lowercase) to wrap your code snippet.

--
best regards,
Anthony

brian101
Offline
Joined: 2010-03-22

hmm...well maybe...

Putting together a small example of this is not an easy thing to do. That is why I wasn't really asking for help as to an alternate technique etc. I've done my research and know what I'm doing on this as well as what is causing the issues...I've left the realm of synchronous drawing of JInternalFrame windows in their natural Z order and now invoke the painting of the visible (clipped) portions in unfixed order (many times over per window as the background thread progresses thru the drawing )

Java doesn't support drawing from any thread but the event dispatch thread...that is why I use java.awt.EventQueue.InvokeLater() every so often to paint the visible portions of the client portion of the windows.

I just wanted to know if there was something in the works to provide a heavyweight JInternalFrame for Swing. If I don't get an answer back within the next few days I may get up the energy to put together a sample.

anthony_p
Offline
Joined: 2006-07-24

Actually the idea to provide support for hw JIFs was meant to workaround some issues that arise when mixing hw and lw components in one component hierarchy (mostly, when adding hw children to JIFs). Obviously, though, that the issue is much more wider than just support for JIFs. Therefore we've implemented a generic hw/lw mixing feature [1] that is available since 6u12. Which consequently means that hw JIFs aren't needed anymore.

As to your problem I suggest starting the thread that builds up the back-buffer separately - *not* from your paintComponent() method (eg. start it in the constructor of your JIF). Let the paintComponent() do what it's supposed to do - take the image drawn so far for that JIF and put it on the screen using the supplied Graphics object. When the thread wants to update the screen, it should just call the repaint() method on its JIF. Swing will handle all the rest.

[1] http://java.sun.com/developer/technicalArticles/GUI/mixing_components/in...

brian101
Offline
Joined: 2010-03-22

Well you answered my question that there are no plans to create a heavyweight JInternalFrame. So thanks for that. As for your suggestion, that is essentially what I am doing (I did exactly what you are suggesting in an earlier iteration) but the problem is that since the lightweight components, when they paint also then cause paints on sibling windows higher in the Z order you still end up with the issue.

I think this points to the reason that heavyweight components exist in the first place. They don't share their screen real estate with other objects, they have advanced clipping etc.

It might be good to add some heavyweight components and let the applications developer decide what is appropriate for their needs. For most of the apps I have done, the lightweight components are fine but at some point you hit a wall. I've hit that wall.

anthony_p
Offline
Joined: 2006-07-24

It still looks like you've been painting to the wrong Graphics object. Could you please provide a sample code that demonstrates the problem (using the second machinery - doing the on-screen painting strictly in the paintComponent(), and preparing the back-buffer on another thread)?

Also, did you override the paintComponent() of the JIF itself, or was it a component added to the content pane of the JIF? I suggest to try the latter.