Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (762)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (847)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Problems with Swing, OGL, 6uN, 1.6.0 and active rendering  (Read 4006 times)
0 Members and 1 Guest are viewing this topic.
Offline cymric
« Posted 2007-12-05 22:00:29 »

Hello,
I started to optimize freerails. First I only wanted to make the game logic much faster, but now I'm lost in swing  Wink
Using the OpenGL rendering pipeline in 1.6.0_03 or the DirectX rendering pipeline in 1.6.0_10-b08 (from the Java SE 6 Update N site) I have the following problem:
The game works and the fps is around 100, everything works ok, as long as I don't open an internal dialog (of type JInternalFrame), then the whole swing gui responds very slow. The weird thing is that the game still runs at 100fps (but now with maximum cpu load), but e.g. mouse events have a delay of 2-4 seconds.
One thing is that the number of events in the SynchronizedEventQueue rises (from 1-2 events/second to 700events/s). Almost all of this came from revalidate() (see stack trace below). The problem occurs with JLabel.setText(). If I generate all possible JLabels at start (at this point the text can have only some values) and instead return them in getListCellRendererComponent(), the GUI does again responds to mouse actions.
If I don't use the OpenGL rendering pipeline, I still have the many Events, but no GUI response problem.
AND I don't have the problem in 6uN build 08 with the OpenGL rendering pipeline!

Had anyone similiar problems?

bye
 Roland

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
Stacktrace:
at jfreerails.client.top.SynchronizedEventQueue.postEvent(SynchronizedEventQueue.java:49)
   at java.awt.EventQueue.invokeLater(EventQueue.java:954)
   at javax.swing.SwingUtilities.invokeLater(SwingUtilities.java:1264)
   at javax.swing.JComponent.revalidate(JComponent.java:4796)
   at javax.swing.JLabel.setText(JLabel.java:325)
   at jfreerails.client.view.TrainSummaryJPanel.getListCellRendererComponent(TrainSummaryJPanel.java:99)
   at javax.swing.plaf.basic.BasicListUI.paintCell(BasicListUI.java:195)
   at javax.swing.plaf.basic.BasicListUI.paintImpl(BasicListUI.java:304)
   at javax.swing.plaf.basic.BasicListUI.paint(BasicListUI.java:227)
   at javax.swing.plaf.ComponentUI.update(ComponentUI.java:143)
   at javax.swing.JComponent.paintComponent(JComponent.java:763)
   at javax.swing.JComponent.paint(JComponent.java:1027)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at javax.swing.JViewport.paint(JViewport.java:747)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at jfreerails.client.view.TrainListJPanel.paint(TrainListJPanel.java:300)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at javax.swing.JLayeredPane.paint(JLayeredPane.java:564)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paintToOffscreen(JComponent.java:5129)
   at javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1382)
   at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1313)
   at javax.swing.RepaintManager.paint(RepaintManager.java:1128)
   at javax.swing.JComponent.paint(JComponent.java:1013)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at javax.swing.JLayeredPane.paint(JLayeredPane.java:564)
   at javax.swing.JComponent.paintChildren(JComponent.java:864)
   at javax.swing.JComponent.paint(JComponent.java:1036)
   at java.awt.Component.lightweightPaint(Component.java:2896)
   at java.awt.Container.lightweightPaint(Container.java:1878)
   at java.awt.GraphicsCallback$PeerPaintCallback.run(GraphicsCallback.java:67)
   at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60)
   at java.awt.Component.paintAll(Component.java:2881)
   at java.awt.GraphicsCallback$PaintAllCallback.run(GraphicsCallback.java:43)
   at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60)
   at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:90)
   at java.awt.Container.paintComponents(Container.java:1865)
   at jfreerails.client.top.GameLoop.run(GameLoop.java:106)
   at jfreerails.launcher.Launcher$1.run(Launcher.java:259)
   at java.lang.Thread.run(Thread.java:619)
Offline cymric
« Reply #1 - Posted 2007-12-05 22:33:37 »

I have added the program and a save game (1.sav, must be put in the same dir as the jar) to sourceforge https://sourceforge.net/project/showfiles.php?group_id=209321  (a new project called freerails2).
If you use the DirectX rendering pipeline you start with a white playfield. Looks like a bug ...

to start the program:
>java -Dsun.java2d.opengl=True -Dsun.java2d.trace=count -jar jfreerails-20071205-2306.jar
select single player, 1.sav and windowed modus
bye
Roland
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #2 - Posted 2007-12-07 00:13:09 »


If you use the DirectX rendering pipeline you start with a white playfield. Looks like a bug ...


I think this could be because you are not using BufferStrategy as carefully
as you should. For example you don't seem to check for contentsRestored()
in your ScreenHandler class. But then again, it may be something different.

The proper loop is shown here:
  http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html

Also, if you use VolatileImages, make sure you validate them
and respond to all validation return codes:
  http://java.sun.com/javase/6/docs/api/java/awt/image/VolatileImage.html
like make sure you loop around contentsLost().

Dmitri
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #3 - Posted 2007-12-07 01:13:34 »

Looks like you do validate your v. images (BufferedTiledBackgroundRenderer.paintRect).

I'd trace and see what happens there on the first repaint.

Something there goes awry and you actually painting to the
screen, not to your BufferStrategy as you think you do.
Most likely because of a race condition between EDT and your
code disabling double-buffering and creating the BS.

Once you draw your volatile image to the screen it will be
lost.

One thing I'd suggest - when you create the BufferStrategy and disable
the double-buffering, make sure you are doing it on the EDT - I think
now you are doing it on the rendering thread.

Thanks,
  Dmitri
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #4 - Posted 2007-12-07 01:27:58 »

Another thought: to prevent rendering to the screen you might try to
override getGraphics() on your game frame, and return the graphics
of your BufferStrategy.

Dmitri
Offline broumbroum

Junior Devvie





« Reply #5 - Posted 2007-12-07 20:08:51 »

I think this could be because you are not using BufferStrategy as carefully
as you should. For example you don't seem to check for contentsRestored()
in your ScreenHandler class. But then again, it may be something different.

The proper loop is shown here:
  http://java.sun.com/javase/6/docs/api/java/awt/image/BufferStrategy.html

Also, if you use VolatileImages, make sure you validate them
and respond to all validation return codes:
  http://java.sun.com/javase/6/docs/api/java/awt/image/VolatileImage.html
like make sure you loop around contentsLost().

Dmitri

those are the options to set properly up :
       - Windows 32 bits:
              java -Dcom.sun.media.imageio.disableCodecLib=true -Dsun.java2d.opengl=False -Dsun.java2d.d3d=True -Dsun.java2d.noddraw=false (Windows does NOT support OpenGL pipeline, nor the native codec libs but the Direct3D pipeline if available)
       - Mac OS X :
              java -Dcom.sun.media.imageio.disableCodecLib=false|null -Dsun.java2d.opengl=True -Dsun.java2d.translaccel=true
       plus the ImageIO.setUseCache(true) is recommended at the beginning of the code.
try surfing about the Java Sun articles if you want more information !             

::::... :..... :::::: ;;;:::™ b23:production 2006 GNU/GPL @ http://b23prodtm.webhop.info
on sf.net: /projects/sf3jswing
Java (1.6u10 plz) Web Start pool
dev' VODcast[/ur
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #6 - Posted 2007-12-07 21:22:11 »

To be honest I don't quite understand how your response has anything
to do with the conversation here. It is also not entirely correct:
Quote
-Dsun.java2d.d3d=True -Dsun.java2d.noddraw=false

That these two together don't make sense. noddraw will turn off both
ddraw and d3d.

Quote
-Dsun.java2d.opengl=False

This one is superficial, the opengl pipeline is disabled by default,
no need to re-disable it.

Thanks,
  Dmitri
Java2D Team
Offline cymric
« Reply #7 - Posted 2007-12-08 23:35:50 »

Hi,
you were right, the first paint was in the EDT. If I ignore paints in the EDT, it works.
Thank you
   Roland

I'd trace and see what happens there on the first repaint.

Something there goes awry and you actually painting to the
screen, not to your BufferStrategy as you think you do.
Most likely because of a race condition between EDT and your
code disabling double-buffering and creating the BS.

One thing I'd suggest - when you create the BufferStrategy and disable
the double-buffering, make sure you are doing it on the EDT - I think
now you are doing it on the rendering thread.

Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #8 - Posted 2007-12-09 02:38:54 »

Good to hear. Although I'd still suggest to disable double buffering
and create BS on the EDT instead of the rendering thread.

Did you see any performance improvements with the fix?

Dmitri
Offline cymric
« Reply #9 - Posted 2007-12-09 11:40:29 »

Hello,
perhaps I misunderstood something about the rendering logic. It uses active rendering and all painting in the EDT is denied. So the fix only affects the first painting.

I have the performance decrease if I open an JInternalFrame (e.g. TrainList), but the main problem is that the GUI with certain configuration no longer reacts on input. The InternalFrame gets rendered to an internal image, I disabled "doubleBuffering" in the  RepaintManagerForActiveRendering, so in the profiler it looks a bit better. With jdk 6uN build 08 and opengl rendering pipeline the problem vanished completely. The framerate in all configuration (directx, opengl, jdk1.6, 6uN) is now always the same (around 50fps).
bye
Roland

Good to hear. Although I'd still suggest to disable double buffering
and create BS on the EDT instead of the rendering thread.

Did you see any performance improvements with the fix?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cymric
« Reply #10 - Posted 2007-12-09 12:08:33 »

Hi,
obviously, the problem is that the SynchronizedEventQueue was blocked 100% of the time, so only a small amount of the Events was processed. A little sleep solved the problem. I think of a better solution, but not today ;-)
bye
Roland
I have the performance decrease if I open an JInternalFrame (e.g. TrainList), but the main problem is that the GUI with certain configuration no longer reacts on input. The InternalFrame gets rendered to an internal image, I disabled "doubleBuffering" in the  RepaintManagerForActiveRendering, so in the profiler it looks a bit better. With jdk 6uN build 08 and opengl rendering pipeline the problem vanished completely. The framerate in all configuration (directx, opengl, jdk1.6, 6uN) is now always the same (around 50fps).
Pages: [1]
  ignore  |  Print  
 
 

 
EgonOlsen (368 views)
2018-06-10 19:43:48

EgonOlsen (374 views)
2018-06-10 19:43:44

EgonOlsen (305 views)
2018-06-10 19:43:20

DesertCoockie (549 views)
2018-05-13 18:23:11

nelsongames (874 views)
2018-04-24 18:15:36

nelsongames (857 views)
2018-04-24 18:14:32

ivj94 (1318 views)
2018-03-24 14:47:39

ivj94 (437 views)
2018-03-24 14:46:31

ivj94 (1100 views)
2018-03-24 14:43:53

Solater (449 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!