Develop Reference

Drawing outside a window in Java?

Is it possible to simply paint() (or use some other function) to the screen in Java? As in draw over everything else on some coordinates of the screen itself, not inside some window.
If not, is it possible to make an invisible window that takes up the entire screen and use its glass pane to do it? Would complications arise from doing this? (Such as not being able to click on other applications)
Are there any other ways?
Thanks.
Edit: I'm not trying to do full screen with this, by the way.

When you paint() in Java, you're painting only within the confines of the size and location of what is being paint()ed.
If you're looking to do full screen stuff, there are tutorials for that:
http://download.oracle.com/javase/tutorial/extra/fullscreen/index.html

In theory, you can create an transparent undecorated maximized JFrame. This will allow you to "paint" over the desktop. Problems are obvious: if an application stays behind this window, it will not receive any mouse events.
Months ago, I made an evil cheat to draw directly on Windows Explorer's Desktop: mixing some .NET coding with JNI and Sun's internal classes - that's surreal, but works.

Fixed size swing GUI changes when using different resolution

I have a small java application with a swing gui. I have set a fixed size for the window and everything works really well. But when using the GUI on different screens, the objects seem to have moved slightly. (Labels not showing their entire text etc,...) I think the difference lies in the aspect ratio of the screen but is there any way to counter this?

The way to counter it is to not used fixed size windows.

I agree with Bryan. There are many reasons - the screen resolution, localization (if you do so), different look-and-feels and rendering depending on the platform and/or JVM version. Swing's layouts are flexible enough to do everything you want without fixing the frame size. Otherwise you are going to implement your rendering engine to calculate everything which is rendered.

Java Window paint problem

My application does not paint itself on startup. When resizing it or minimizing/maximizing it, the window of the application is painted.
This problem only appears on Windows machines (I tested XP, Vista and Windows 7). On Mac OS X and Linux, the application works fine.
The machines have installed java 6. My application uses the AWT, so not Swing. I tried using Swing (so JFrame in stead of Frame), but this does not solve the problem.
I checked the calls on repaint(), update() and paint() of the frame. They all appear, and the image to draw is available. I also checked if these calls are done on the EDT thread. This is the case. When the window is resized (or min/max-ed) a call on paint() is done by the system, and the image is drawn.
My fear is that I'm missing something really obvious. I'm making the frame visible, validate it (also tested with invalidate) and repaint it. This is sufficient in Mac OS X and Linux.
Does somebody have any suggestions to what I should do, or what else to try?
Thanx in advance
Maurice

My guess is that you are overriding Frame.paint. You will probably get better results from painting to a JPanel (or Canvas, if you insist on the obsolete AWT), and when you do that, make sure you're overriding JPanel's paintComponent, rather than paint. In some cases, a JLabel with an ImageIcon can be simpler still.
As others have suggested, though, try to post a test case.

You might want to check out this debugging trick using a custom RepaintManager. It helped me track down some tricky intermittent swing glitches.
http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html

It is difficult to diagnose the problem without seeing any source code, but is the image fully loaded?
AWT loads images in the background after, so even though a call to Toolkit.getImage() may return a valid Image instance, this does not mean that the image is loaded by that time. You can use a MediaTracker to track this.

Are Java GUIs always slow to update or is it just me?

I've just started making my first GUI application in Java and I decided to use the NetBeans IDE to do it. I think its working fine so far, except for one problem; it seems to be slow updating the content of a window.
Even in very simple windows with few controls I find that when - for example - closing or resizing a window, I get the normal window border working properly but the inside is completely see through for a second.
It's not the biggest deal in the world, I just find it mildly annoying.
EDIT: I've tried the HelloWorldSwing from the official Java tutorial but I have the same issue, only now, when resizing, instead of being transparent, the new area of the window is black until the contents updates.

You should ensure that all of your GUI updates are performed in the Event Dispatch Thread, and that any other long running tasks are performed in worker threads. If you have long running tasks running in the EDT, your GUI will feel sluggish. Take a look at this tutorial for concepts on Swing Threading.

In the absence of any technical problems with your app, this could simply be JVM warmup effects. Do updates speed up if you resize the window a few times?

This could be a Java2D hardware accelleration issue. Is your 3D graphics card driver fully updated?

Java Applet, AWT Refresh, issue on Mac OS X 10.4

We have a Java Applet built using AWT. This applet lets you select pictures from your hard drive and upload them to a server. The applet includes a scrollable list of pictures, which works fine in Windows, Linux and Mac OS X 10.5. We launch this applet via Java Web Start or within a web page.
Our applet does not behave properly in Mac OS X 10.4, regardless of the version of Java (1.4 or 1.5). You can find a screenshot of the incorrect behaviour, when scrolling, here:
http://www.lavablast.com/tmp/ui_error.png
Simply put, sometimes when scrolling the pictures end up overlapping the header or footer of the application. This behaviour does not occur on other platforms. On Mac OS X 10.4, it shows the pictures in the incorrect location when scrolling, which would not be so bad if it refreshed the screen after painting the image at that location. However, it does not appear that the application knows it painted it incorrectly and thus does not refresh.
If the window is minimized, resized or even moved, the application is refreshed and the incorrectly positioned elements vanish and the application resumes normally. I spent quite some time trying to force a refresh of the background image unsuccessfully. (the repaint the image directly, repaint all children of a few panels, etc. ) Thus, I am looking for any tips that would help me resolve this problem under Mac OS X 10.4 or, in the worst case, simply simulate a full applet refresh.
Until recently, everything was compatible with Java 1.1 but this has changed in a few locations which now require 1.4. I don't feel these changes created the issue, I am just providing this as extra information. If you are interested in implementation details of the scroll panel, I will investigate, but I am assuming this is a common platform bug for which workarounds must be known.
To replicate the problem, open the following Java Web Start application:
http://www.lavablast.com/tmp/opal-webstart.php.jnlp
Select a folder containing lots of images and play with the scrollbar. At some point (fairly quickly), you should get the refresh problem.
Edit: I followed the first suggestion here and replaced all my controls that feature background images with a Swing equivalent and the issue is still there. (Plus, there are numerous other fixes I would need to do to do a complete change). Any other ideas? A simple one line of code that forces a full refresh would be great :)
Edit2: The main thread creates the panels and launches X threads. Using an observer/notifier pattern, the threads complete and notify the main control, which adds a panel to the page. This is done via an EventQueue.invokeLater which, unless I am mistaken, should run on the right thread. The issue is at its most severe when scrolling even if no extra threads are running (as during the loading).

It does look like mixing lightweight (usually Swing) and heavyweight (AWT) components together. Moving to Swing you need to replace every last AWT component Swing equivalents (hint: avoid import java.awt.*).
Threading is often a potential problem for odd bugs. Swing components must always be used on the EDT (use java.awt.EventQueue.invokeLater). AWT is thread-safe is theory, but not in practice - also restrict usage to the EDT.

As you already require Java 1.4 you should consider some small changes to take into use SWING GUI instead, it solved our Applet refresh issues with AWT. (Mac, Linux etc)
If you have e.g. Panel, you need to replace it with JPanel etc.
You need this:
import javax.swing.*;