I have a Java Applet that uses AWT. In some (rare) circumstances, the platform does not refresh the screen properly. I can move or minimize/maximize the window and see that my applet refreshed properly. I am looking for code that will give me the fullest possible applet screen repaint, simulating the behaviour of a minimize/maximize.
I've tried calling various combinations of paint()/repaint()/invalidate()/update() on the parent containers and recursing on various children. However, no combination (that I've found) cleans up the framework bugs that I am encountering. I am looking for techniques to fully refresh the applet, even if they may cause some slight flickering, as I will be invoking this code only on the problematic platform.
In my tests, moving to Swing did not help resolve my problem.
By the way, this is a simplification of my previous (more complicated) post: Java Applet, AWT Refresh problem Mac OS X 10.4
Edit: Investigation in threading did not solve this problem. Marking best answer as the good one.
This happens all the time if you are not programming carefully in AWT/Swing.
First of all, you should do ALL work on the event thread. This means you can't do any of it in your main statement (or anything it calls directly). I know every Java GUI app ever invented violates this rule, but that's the rule.
For the most part, they used to say you could use a non-awt thread until the window was "Realized" (pack/setVisible), but Sun figured out that didn't always work.
Second, when you get an event on the AWT thread, be sure to return it quickly. Never sleep or execute a long operation.
Third, (and this is an extension of "First", if you get a callback that is NOT already on the AWT worker thread, be sure to put it on the AWT thread before doing anything with the GUI.
Generally, any event generated by an AWT component will be on the correct thread. Events generated by timers, manually created threads, or the one handed to main() are not.
The method to use for this kind of problem is repaint, as you've mentioned. It's possible you are seeing an issue with the JVM you are using. I'd recommend using different versions of the Sun JVM and even the MS VM for IE to see if this is a VM related problem - it may actually be unrelated to your code.
I haven't actually tried this before, but a creative way (ie. nasty hack) around this might be to execute javascript from the applet to call a DOM method to do a mock resize of the window or perhaps call focus on the body in an attempt to cause an external re-drawing of the canvas.
Not sure if this is related to what you've seen, but if you get up against the performance of the AWT Event Queue the java 2d + 3d world (graphics pipeline folks) will point into a threaded strategy and then you'll get into the dispose problem.
This discussion has been looking at designs employing the AWT Event Queue for graphics, as in using "repaint".
In the threaded approach, there is a shutdown problem.
Notes in java/awt/SequencedEvent for "dispose" point us to "AWT Threading Issues" and "Autoshutdown".
I'm thinking that this bit of info serves at least to focus the problem.
I was able to fix 99% of my AWT Applet redraw issues by switching to Swing. Swing seems to be more reliable on refreshing.
Earlier I had a lot of manual repaints() in my applet code, but with Swing these were removed and applet is now faster especially under Terminal Server / LTSP.
I placed critical stuff inside this:
public class VeryFastPanel extends JPanel {
/**
*
*/
private static final long serialVersionUID = 1L;
public void update(Graphics g) {
paint(g);
}
}
I found an issue that appears to be the same you are experiencing. After some tests, I discovered that this can be related to Aero and Intel Graphics adapters. In my case, the application stopped repainting only when used in notebooks without AC adapters, powered by batteries. If you disable some power saving features in Intel driver configuration (notably Intel 2D Display Technology in old driver releases) Java will repaint normally again.
In my case I found also ways to disable this option via registry. It's not documented, but it works.
Related
we have a strange problem with our GUI after changing to Java 1.7.
Sometimes if the user starts our Application it seems to be freezed, but probably there is just no repaint, because if user tries for example to scroll, changes the window and comes back to application the scroll changes are visible.
And the problem will be solved if the users change to fullscreen.
I tried to search for this problem, but the only thing most related to it was an unanswered question here:
http://www.java-forums.org/awt-swing/31107-intermittent-freeze-javawebstart-swing-app.html
May be anyone of you had the problem and know the solution?
The migration to Java 7 may have exposed a latent problem in the original code. Here are some things to look at:
Some APIs, especially among the text components listed here, are no longer marked thread safe in Java 7.
You can search for EDT violations using one of the approaches cited here.
Resizing the enclosing Window generates an automatic repaint(); if your updates are otherwise correctly synchronized, you can sequence your own repaint() using invokeLater().
Verify that setVisible() is last in your initialization, after pack().
Does X-Windows have to be installed on a Linux-box in order for Java to display fullscreen graphics?
Well "fullscreen graphics" is a bit vague.
Anyway, apparently there is a an effort ongoing to access the framebuffer from Java: Framebuffer Toolkit.
The objective of this project is to produce a body of code which is
a lightweight framebuffer-based peer implementation for AWT and Swing.
The goal of this code is to remove the dependency on X or
other graphics layers such that graphics can be redirected to
a framebuffer (e.g. a raw buffer, VNC, etc.). This example
implementation will prefer pure-Java solutions, with public
extension points available to enter native resources as necessary.
See Project proposal: fbtoolkit.
Other answerers appear to assume that "full screen graphics in Java" necessarily means "a working implementation of AWT". This is, of course, not necessarily true, as it is perfectly possible (some would even say desirable) to use Java without AWT.
Cairo is a 2D graphics rendering library that can be used from Java, and can also be used without X11. It looks at first glance as though it should be possible to configure it for this scenario. You'll need to configure it to use OpenGL rendering, and provide a suitable non-X11 OpenGL implementation (e.g. MesaGL with the 'fbdev' device driver).
SDLJava is a Java port of the popular C SDL game development library. This also should be able to do what you ask for, although it doesn't seem to have been updated since 2005 so if you have any problems with it support may not be forthcoming.
As an alternative, you could always use some fairly simple C code to open and configure the framebuffer, and then use JNI to return the memory-mapped framebuffer as a direct-mode ByteBuffer, so you can draw to it directly.
To really display something graphical on the screen, yes. Bud there is a headless version of the JRE for just running it. You won't see any graphical output, but it will run.
Alternatively, you can log in remotely and use X forwarding to run the java code on the server but let the client handle displaying graphics.
On an embedded device, such as a Raspberry Pi, if you don't want to go through full X11 with standard Java AWT + Swing, then this https://github.com/ttww/JavaFrameBuffer project to write straight into the frame buffer seems interesting.
An alternative may be to use e.g. SWT on GTK, or Qt Jambi, to write into the Frame Buffer (both GTK and QT can directly use a FB without X11).
I am doing a school java project using the NetBeans IDE. It includes some basic database manipulations. We were taught at school to use the following for linking one form to another:
new <form_name>().setVisible(true)
But this seem to slow down the whole application and there is a small lag for going from one form to another. I heard that using JDialog boxes is a solution to this problem.
So what's the right way to do it?
Better to not swap in and out of different JFrames. How many professional applications such as word processors do you use that do this that throw different windows at the user? Better to use one main JFrame and swap views (usually JPanels) in it via a CardLayout and occasionally show a dependent Window as a dialog when needed, especially when you need to get information in a modal way.
some basic database manipulations. .. But this seem to slow down the whole application
Don't block the EDT (Event Dispatch Thread) - the GUI will 'freeze' when that happens. Instead of calling Thread.sleep(n) implement a Swing Timer for repeating tasks or a SwingWorker for long running tasks. See Concurrency in Swing for more details.
(But also see #Hovercraft's advice re. CardLayout..)
I would like to create a new event-dispatch thread in Swing, and I'm having trouble finding any references online for how to do this. I have done this in .NET by creating a new thread and calling Application.run(...). Has anyone done this? Is it possible in Swing?
FYI the reason I am trying to do this is because I am writing an Eclipse plug-in, and I would like to pop up dialogs that are not modal to the IDE but that are modal (blocking) to my UI logic. I could accomplish this using non-modal dialogs and callbacks, but that requires the overhead of making my code multi-threaded. I'll revert to that if the former is not possible.
Yes, it's possible. I've have done such multiple EDT dispatch threads logic in Swing. However, net result was that it didn't work reliably.
(a) All JVMs don't work nicely with multiple EDT threads (synchronization problems in graphics rendering logic in native code and such, IBM JVM failed with multiple EDT threads, Sun JVM & Apple JVM did work)
(b) Swing rendering logic has few bugs causing that random rendering errors will occur (for example, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6727829).
Anyway, doing this requires basically establishing two AppContexts, which each have their own EDT thread.
I'm a little confused by your question, because you mention Swing but then say you are writing an Eclipse plugin. Since the question is tagged Swing, I'll give a Swing answer (but posted as CW).
There is one event dispatch thread. There is always one event dispatch thread, unless there is none at all. You cannot create another one.
You can, however, change the ModalityType of your dialogs, or change the ModalExclusionType of a window. In this case, if you were writing this all yourself, you would set your top-level window's ModalExclusionType to APPLICATION_EXCLUDE.
But again, I don't see how this could help you, since Eclipse uses SWT instead of Swing.
I'm going to junk my last answer and start anew.
In SWT, you can create Shells (windows) or custom Dialogs that are modal just to the parent by passing the SWT.PRIMARY_MODAL style flag during creation.
Note that Dialog is an abstract class, so you'd have to create your own. It's probably just easier to use Shell.
Edit:
Why SWT? Because that's what Eclipse uses. See: Eclipse Platform Plug-in Developer Guide (zipped PDF) for more details. The most recent version is available in Eclipse's Help system (Help > Help Contents > Plug-in Development Environment Guide.)
I'm looking for a way to know in a Java application (without JNI - it's a multi-platform application) can detect if the screen is locked.
For information... our application records time while a user is working - we want it to automatically stop recording when the screen is locked instead of the user having to do so explicitly.
I don't think there is an API for that or even a way to do it all. Parsing screenshots generated by java.awt.Robot is neither platform- nor version- or even configuration-independant, and in general, I don't think "screen is locked" is a well-enough defined concept to be used in this sense - on Linux, there can be more than just one "screen" (X server), you can switch to console terminals, you can have applications running one (or more) machines display their GUIs on another machine over the network...
I confirm there seems to be no Java API to detect a screen lock status.
Spark developer gave it a try in 2006 (like this thread shows), but without giving out any details on the specific of the implementation.
However, it is likely it involved JNI and native call to functions like WTSQuerySessionInformation (To detect if disconnected use WTSQuerySessionInformation(NULL, WTS_CURRENT_SESSION, WTSConnectState) and look for WTSDisconnected).
So, as Michael pointed out, there is no "multi-platform" universal answer (to the best of my knowledge).