We have a Java/Swing client that's been around for quite a few years. When I moved from XP to Vista (client ONLY runs on Windows), I noticed that whenever a new window is created (usually a JFrame descendant) on my secondary monitor, the window initially shows as blank, i.e. instead of showing the normal contents of the window, it's just a solid block of gray. If I then drag that window onto the primary monitor, the second it crosses the monitor boundary, it draws itself properly and I can drag it back to the secondary monitor. If the window is created on the primary monitor, it always comes into existence perfectly. I NEVER had this problem on XP, only on Vista. I'm unable to easily test it on Windows 7, lacking a dual monitor Windows 7 machine.
Anybody have any ideas? Is this perhaps a known Java bug? I'm also running the most recent Java 1.6 SDK.
Check that the video driver and the JRE are up to date. (It is possible to have a current JDK, but an old JRE.)
Java will delegate the buffering to DirectDraw and/or Direct3D. You can disable this with the following JVM options:
-Dsun.java2d.d3d=false
-Dsun.java2d.noddraw=true
There are other options detailed here.
If the primary monitor is to the right of the secondary monitor, the screen positions on the secondary monitor will have negative X values. (Likewise if the secondary is above the primary positions will have negative Y values.) It is possible there is code that is not handling the negative values.
Related
Hi I'm working on a group project and the code works on my teammate's PCs but I keep hitting MacOS specific errors. And this time I seem to be stuck (no easily Googleable answer).
In a previous post I discovered I need "-Djava.awt.headless=true" as VM setting to properly run my simulation. Now when I try to spawn in some JFrame they are all met with a lovely "java.awt.HeadlessException" Exception because of that VM flag.
Trying to achieve
I want to be able to spawn those JFrames on my MacBook also.
The problem
I need -Djava.awt.headless to be both true and false at the same time for my program to run properly on Mac. Which if I understand my problem correcly, means I have a big problem on my hands.
EDIT: running it in a VM on my Macbook allowed me to run the project properly. This is far from an ideal fix. I'm still searching for a solution to this obscure problem.
What I tried
not running with the VM option: the problem described in previous post occurs. Thus this is not a viable option
running with the VM option: this throws a -Djava.awt.headless when creating a JFrame.
The best way to fix this may be by going back and solving your original problem a different way.
You must make sure that you are not initializing your BufferedImage in the main thread (GLFW thread), it MUST be done separately. It is hard to tell from your original question, but that looks like part of the cause there. Start a new thread to do the image processing instead.
See my solution and recommendation at the bottom of this answer for a quick summary, and also see here for someone else that had the same issue: Java Creating Instance of BufferedImage Freezes Program
A quick note on why your code works on Windows and not Mac: that is because both OS often run different implementations of openGL, and typically Mac can lag behind and miss out on a bunch of updates/changes that may solve problems like this one so that it doesn’t freeze when initializing a BufferedImage on the openGL thread.
If the above didn’t work then lets first look at what headless mode is. (Emphasis mine):
See link at bottom for full article and more info.
Headless mode is a system configuration in which the display device,
keyboard, or mouse is lacking. Sounds unexpected, but actually you can
perform different operations in this mode, even with graphic data.
Where it is applicable? Let's say that your application repeatedly generates a certain image, for example, a graphical authorization code
that must be changed every time a user logs in to the system. When
creating an image, your application needs neither the display nor the
keyboard. Let's assume now that you have a mainframe or dedicated
server on your project that has no display device, keyboard, or mouse.
The ideal decision is to use this environment's substantial computing
power for the visual as well as the nonvisual features. An image
that was generated in the headless mode system then can be passed to
the headful system for further rendering.
So when should headless mode be used:
On a machine that has no display device, keyboard, or mouse.
That is not you is it? However if that is you (LWJGL?), then lets look at how you can work with headless mode:
An image that was generated in the headless mode system then can be
passed to the headful system for further rendering.
This means that you should have a special piece of headless code that does your headless image stuff, but then passes the image back to a normal JFrame with a head.
So why does it fail for you:
Many components are affected if a display device, keyboard, or mouse
is not supported. An appropriate class constructor throws a
HeadlessException
Button
Checkbox
Choice
Dialog
FileDialog
Frame
Label
List
Menu
MenuBar
MenuItem
PopupMenu
Scrollbar
ScrollPane
TextArea
TextField
Window
Solution to the problem:
some classes, such as Canvas or Panel, can be executed in headless mode.
Perfect, so we just need to be careful what is used in headless mode. You asked how you can both use and not use headless mode, well rather than globally setting headless mode with VM option -Djava.awt.headless you can do it programmatically within your code using System.setProperty("java.awt.headless", "true"); where needed. A JFrame should be normal (not Headless), but you can spawn a JPanel as headless without issue.
I recommend:
You create a normal headed main thread with no VM option that spawns JFrames, and then use that main thread to spawn a new child thread and set your LWJGL bits in that thread to be headless, and that way you can run your LWJGL code without issue, and at the same time you can still have JFrames from your main thread. Remember to make sure that the Buffered image is not done in the main LWJGL/OpenGL thread.
Headless info source:
http://www.oracle.com/technetwork/articles/javase/headless-136834.html
Environment: Windows 7, JRE 8.65, observed with both yEd 3.14 and GanttProject 2.7.1 (also previously observed on Win XP.)
Can the program's main window take focus (not auto-raise) without being atop other windows and without clicking in it? (nothing found in 917 results from a StackOverflow search on the words "Java" "window" and "focus", though I was getting bleary-eyed by the end.)
The problem is that when I move the pointer into or across the program's window, that window does not activate, though it activates the icon in the "task bar" (which is auto-hidden.) It is clear that the program recognises the pointer's existence and focus change, but the main window never actually takes the pointer (i.e. the main window remains inactive, and requires that I click in it to activate it; which raises it, which is exactly the behaviour I try to avoid with F-F-M.)
This is more troublesome because when the icon in the task bar activates, the task bar covers a chunk of my screen and won't go away until the main program window is activated by clicking in it. Simply moving the mouse from one place to another on the screen has about a 30% probability of touching (and half-activating) one of these program windows, forcing me to locate the window, click in it, minimise it, then get back to what I really was trying to do. (Yes, my "desktop" is a jumble, but everything has its place and normally I can rapidly navigate among the dozen or so windows that are truly useful.)
Thanks for any pointers or advice. (Though suggestions that I change my behaviour probably won't be followed.)
This problem occurred to me as well. The only workaround I got so far is using JRE 6 if possible since this annoying behavior started with JRE 7.
When a new monitor is added to a PC or a laptop that's already running a JRE instance, we find that the monitor just added is not considered an extension of a larger virtual screen, but rather JRE creates two separate virtual screens (each with (0,0) as the upper left coordinate as indicated by the GraphicsConfiguration associated the list of devices retrieved using getScreenDevices()). Restarting the JRE fixes the problem (i.e., the two screens are now treated as part of a larger virtual screen with separate starting coordinates).
My question is: How do you correctly determine the monitor (GraphicsDevice) instance where a Java Applet is currently displayed under the following circumstances:
1. The user adds a monitor to his PC/laptop
2. User drags the browser window running the Applet and repositions it in the new screen.
3. Any JDialog or other frames need to open in the new screen, but this can only be done if we can automatically detect the screen instance where the Applet was repositioned.
As mentioned earlier, simply checking the position of the Java Applet against the bounds of the graphics configuration of the various screens does not work, as the bounds all start at (0,0).
I don't want my users or customers to have to kill and restart their Java.exe just because a new monitor was added so that screen instances can be correctly melded by JRE into a single Virtual Screen. Any ideas?
I'm developing a Swing-based Java application in Eclipse on Windows XP. I have a dual monitor setup.
I want to have the program launch on a different monitor than the one I'm running Eclipse in. How can I set up my Debug Configuration to make this happen?
When a new frame is opened, it defaults to coordinates 0,0. Exactly where this is depends on your operating system's monitor layout. Typically, 0,0 will be the upper-left corner of the primary monitor.
The solution to your problem is to run Eclipse on your secondary monitor, so that the applications will open on the other (primary) monitor. You don't actually have to move Eclipse to do this. Go into your operating system's monitor settings and switch the primary monitor to the monitor you wish to start the application on. Eclipse will now be running on the secondary monitor.
Your new frame will now be opened on the other monitor, and you have changed no code in the process, just your operating system's configuration settings.
It depends a bit how you did set up your second monitor. For my answer, I'm assuming that you added it as an "extension" to your desktop (so you can move windows between them by dragging with the mouse).
In this mode, your desktop becomes bigger. To see that, call GraphicsEnvironment.getLocalGraphicsEnvironment().getMaximumWindowBounds.
The width should be the sum of the widths of your two monitors and the height should be the larger of the two heights.
Note that the x coordinate can be < 0 (this happens if your make the right monitor the default one).
To move your window to the other monitor, simply use a position (setPosition()) with an appropriate value and pass that position as an option to the program. Or save the current position as a preferences node and open the window again in the same place when the app is run again.
If your monitors are configured independently, you should look into the GraphicsEnvironment.getScreenDevices() API.
I think you can't do that. The only solution I found is to move the program from the first display to the second one manually and then close it in this position (with the close button and not the Console terminate red button that stop brutally the VM without saving anything). Then on the next restart, your program launch should appear on the second display. In order to have this solution working, your launch configuration should not clear the workspace and the config at each launch in order to keep the programm screen location.
See RCP opening monitor for related stuff on RCP app.
You can probably achieve that behavior programmatically. I'm sure you can Google and find examples of how to open your window on the second monitor. If it is something you want only at debug-time, add a switch in your launch configuration (more specifically, a JVM runtime argument) and check for the switch (System.getProperty) when your program starts.
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.*;