Transparency

[zirbinator]

Hello all,

I have a strange question about a drawing speed issue that I have been having on non-Windows systems (currently only tested on Ubuntu and OS X, but I'll bet it's similar for other Linux distributions). I've been working on a game-like program that uses what I take to be a standard update/draw loop, so that each draw cycle has to take less than, say, 20 milliseconds. The project's been going great, but I recently tried to run it on Linux, and things didn't work out so smoothly. Instead of draw times of about 5 milliseconds that I had been getting in Windows, drawing took upwards of 6 seconds. I've never had problems like this before, so my first reaction was that I'd done something horribly wrong with my code, so I rewrote my basic draw loop into a simple test program. I put a couple simple instructions (fill the background and draw a few lines) and it ran very nicely, until I tried making the colors translucent. Then it started to take a ridiculous amount of time drawing again. Here's my code:

package main;

import java.awt.Color;
import java.awt.Graphics2D;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Rectangle;
import java.awt.Toolkit;
import java.awt.event.KeyEvent;
import java.awt.event.KeyListener;
import java.awt.image.BufferStrategy;

import javax.swing.JFrame;

public class DrawTest implements KeyListener
{
	JFrame frame;
	
	Rectangle screen;
	
	public static void main(String[] args)
	{
		DrawTest dt = new DrawTest();
		dt.init();
		dt.run();
	}
	
	public void init()
	{
		frame = new JFrame();
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setUndecorated(true);
		frame.setResizable(false);
		frame.addKeyListener(this);
		
		GraphicsEnvironment environment = GraphicsEnvironment.getLocalGraphicsEnvironment();
		GraphicsDevice device = environment.getDefaultScreenDevice();
		screen = new Rectangle(0, 0, device.getDisplayMode().getWidth(), device.getDisplayMode().getHeight());
		
		device.setFullScreenWindow(frame);
		frame.createBufferStrategy(2);
	}
	
	public void run()
	{
		while(true)
		{
			long before = System.nanoTime();
			
			BufferStrategy strategy = frame.getBufferStrategy();
			Graphics2D g = (Graphics2D)strategy.getDrawGraphics();
			draw(g);
			g.dispose();
			strategy.show();
			Toolkit.getDefaultToolkit().sync();
			
			System.out.println("Time: " + (System.nanoTime() - before)/1000000);
			
			try
			{
				Thread.sleep(50);
			}
			catch (InterruptedException ex) { }
		}
	}
	
	public void draw(Graphics2D g)
	{
		g.setColor(Color.black);
		g.fillRect(0, 0, screen.width, screen.height);
		
		// opaque
		g.setColor(Color.red);
		for (int i = 0; i < screen.width; i += 10)
		{
			g.drawLine(i, 0, i, screen.height);
		}
		
		// transparent
		g.setColor(new Color(Color.red.getRed(), Color.red.getGreen(), Color.red.getBlue(), 50));
		for (int i = 5; i < screen.width; i += 10)
		{
			g.drawLine(i, 0, i, screen.height);
		}
	}
	
	public void keyPressed(KeyEvent event)
	{
		if (event.getKeyCode() == KeyEvent.VK_ESCAPE)
		{
			System.exit(0);
		}
		event.consume();
	}
	
	public void keyReleased(KeyEvent event)
	{
		event.consume();
	}
	
	public void keyTyped(KeyEvent event)
	{
		event.consume();
	}
}

In Windows, the printed values (in milliseconds) were usually 0 or sometimes 1, but in Linux it took about 10 seconds to simply run through the draw() method once. When I took out the transparent lines, it ran in 0-1 milliseconds per loop. I have no idea why it would be so slow for transparent lines (and other shapes, etc.) just in Linux. Another strange thing is that drawing translucent images doesn't slow down the program nearly as much as these lines because I do it in a different way than setColor().

So, my question is: is transparency not supported on Linux/Mac, or am I doing something wrong? Anything about faster ways to draw transparent lines, etc. is greatly appreciated.

[jaho]

Maybe you should try to enable the opengl on your linux, also linux is not supporting all the graphics cards fully.

-Dsun.java2d.opengl=true

Line i typed enables the opengl support if it is installed and supported by the linux you are using.

[KevinWorkman]

Is there a reason you're doing your painting that way? It's usually not a good idea to explicitly request the Graphics for a Component, unless you really do want to do active rendering. I recommend you read this: Lesson: Performing Custom Painting (The Java™ Tutorials > Creating a GUI With JFC/Swing)

[zirbinator]

jaho:

This seemed to be just what I was looking for. It runs a lot more smoothly on Linux - specifically Ubuntu 11.10, so thanks (though it actually seemed slower on Windows for some reason). Do you know of any way to activate OpenGL in the program? It's easy enough for me to use command-line arguments on my own, but if I send my program to someone, it would be a lot easier if I didn't have to explain how to run it command-line. Thanks!

KevinWorkman:

As far as I know, this is the standard way to draw graphics in a game (or something like a game). The standard options that Swing/AWT/etc. give don't allow you to control things like framerate, etc. In this case, it would be better to use paintComponent() and Swing because it's drawing the same thing over and over again. But in my actual program the scene is constantly changing, and it's not practical to rely on Swing, like you can for a GUI. At least this is how I've seen it in all the books I've read on games in Java.

[KevinWorkman]

KevinWorkman:

As far as I know, this is the standard way to draw graphics in a game (or something like a game). The standard options that Swing/AWT/etc. give don't allow you to control things like framerate, etc. In this case, it would be better to use paintComponent() and Swing because it's drawing the same thing over and over again. But in my actual program the scene is constantly changing, and it's not practical to rely on Swing, like you can for a GUI. At least this is how I've seen it in all the books I've read on games in Java.

Right, this is one way to do active rendering, but for many purposes, including many games and this instance, that's not necessary. All you need is a game loop (a Timer or a Thread) that fires at a frequency equal to your framerate and then a call to repaint() that paints the scene. In my experience, most people having trouble with active rendering don't really need it in the first place.

[zirbinator]

Right, this is one way to do active rendering, but for many purposes, including many games and this instance, that's not necessary. All you need is a game loop (a Timer or a Thread) that fires at a frequency equal to your framerate and then a call to repaint() that paints the scene. In my experience, most people having trouble with active rendering don't really need it in the first place.

From what I've read, calling repaint() does not actually call paintComponent(), but it queues a paint event, to be called as soon as possible, which isn't quite good enough for most games (for one thing, there's more to rendering than just what's in paintComponent()). I've also found that it can be helpful to directly control graphics for things like double buffering and creating optimized volatile images. In any case, I'm sure that the actual program I'm writing (*slightly* more complicated than this example) does require active rendering, but thanks for the critique!

[DarrylBurke]

From what I've read, calling repaint() does not actually call paintComponent(), but it queues a paint event, to be called as soon as possible

... with the possibility of coalescing pending paintEvents into a single call to paintComponent(...).

db

[nicephotog]

public class DrawTest implements KeyListener,Runnable
{

I think it could be trying to tell you something albeit it compiles?!
I presume you recompiled in Linux to see how that version and tool compared and operated on the code?

Also, why are you using a Thread when you want to use a Swing timer javax.swing.Timer or java.util.Timer (one of these two timers allows throwing away useless extra-overlapped calls until separated), SLEEP(LONG) does that but with the "Thread" its exactly that! it will start and stop also accorded "system OS calls" beyond your control so you need to not overlap the the threads and need to build checking locks.
The main way of controling it is to setPriority();
so first line of constructor after assigned arguments if the class is a Runnable interface
put
thrd = new Thread(this); // this runnable -- put a global var declaration
thrd.setPriority(10); // max = 10 , normal = 5 , min = 1


As that also is, class java.awt.Component has a method
use eaxample
cmpnt.repaint(((long)50L)); // repaint(milliseconds long)


===

AS FOR Transparency

public interface Transparency java.awt.Transparency

also lookup java.awt.image.BufferedImage for Alpha alpha raster and Alpha algorithms.