Bug 726 - First GLWindow in first NewtCanvasAWT doesn't get .repaint(), when there are other windows
Summary: First GLWindow in first NewtCanvasAWT doesn't get .repaint(), when there are ...
Status: RESOLVED INVALID
Alias: None
Product: Newt
Classification: JogAmp
Component: awt (show other bugs)
Version: 1
Hardware: pc_x86_64 windows
: --- normal
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2013-04-29 23:12 CEST by Michał Rus
Modified: 2013-05-02 20:43 CEST (History)
2 users (show)

See Also:
Type: ---
SCM Refs:
Workaround: ---


Attachments
Archive with test.log, test_dbg.log and an application showing the bug. (222.97 KB, application/octet-stream)
2013-04-29 23:12 CEST, Michał Rus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Rus 2013-04-29 23:12:26 CEST
Created attachment 458 [details]
Archive with test.log, test_dbg.log and an application showing the bug.

GLWindow is added to JInternalFrame using NewtCanvasAWT.

Only the last window (order of creation) gets automatically repainted when any other window moves over it.
Comment 1 Michał Rus 2013-04-30 03:37:54 CEST
http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html

See this fragment:

"The capability to mix heavyweight and lightweight components works by default, if you are using the JDK 6 Update 12 release or the JDK 7 build 19 release. In most cases, this functionality will just work, but there are a few situations that might affect your code:"

Might that be the case?
Comment 2 Julien Gouesse 2013-04-30 09:29:19 CEST
> Might that be the case?

Yes because you use JInternalFrame but it would be fine to make it work.
Comment 3 Michał Rus 2013-04-30 10:18:31 CEST
(In reply to comment #2)
> > Might that be the case?
> 
> Yes because you use JInternalFrame but it would be fine to make it work.

So what would be the current workaround? I mean, until this is fixed?
Comment 4 Julien Gouesse 2013-04-30 14:11:54 CEST
(In reply to comment #3)
> (In reply to comment #2)
> > > Might that be the case?
> > 
> > Yes because you use JInternalFrame but it would be fine to make it work.
> 
> So what would be the current workaround? I mean, until this is fixed?

Use a GLJPanel :s
Comment 5 Julien Gouesse 2013-04-30 14:15:23 CEST
Please try to use an animator. You can create your own animator by overriding an existing one and incorporating your specific behaviour in order to avoid repainting when it is not required.
Comment 6 Michał Rus 2013-04-30 15:57:24 CEST
:) But my overriden animator, when in state of "avoiding-repainting-when-it-is-not-needed", will still not repaint the window when another window overlaps with it...
Comment 7 Julien Gouesse 2013-04-30 16:30:19 CEST
(In reply to comment #6)
> :) But my overriden animator, when in state of
> "avoiding-repainting-when-it-is-not-needed", will still not repaint the
> window when another window overlaps with it...

Then don't try to follow the repaint-on-demand idiom. This idiom is easy to follow in a monolithic GUI with a single canvas. It becomes very complicated to implement when there are several frames which can overlap each other except if you succeed in detecting these overlaps. You can use an imposter too, by rendering the scene into a texture and showing it when nothing changes. You can use GLOffscreenAutoDrawable.FBO to render a scene in a texture. Then, you can trigger the rendering only when necessary, you can always display this texture and you can use a plain animator.
Comment 8 Michał Rus 2013-04-30 18:51:13 CEST
THANK-YOU! =) <3 Ingenious idea and works.
Comment 9 Sven Gothel 2013-05-02 20:40:18 CEST
Not that I have followed the discussion below, but I see some sort of satisfaction
and hence I close this entry.

Please reopen if this is a bug from JOGL, doesn't look like.
Comment 10 Michał Rus 2013-05-02 20:43:21 CEST
Sven, I was satisfied with a work-around, the bug is still there. It's about mixing heavyweight (GLWindow) and lightweight (JInternalFrame) components.