1

I have been doing some reading and have found out that the Java Swing cannot stay on top of full screen applications without a horrible flickering effect. Is this true? The flickering effect: I have a thread that updates the frame.setAlwaysOnTop() to true every 200ms.

If it is I was looking for an alternative to method to do this in and was reading about C/C++/C#s SetWindowsPos and it looks like this would do it for me. However, before I rewrite my program I want to know if this will allow me to keep my program on top of another fullscreen application. Thanks

Dan Bradbury
  • 2,071
  • 2
  • 21
  • 27
  • What "flickering" are you talking about? I've used `setAlwaysOnTop()` without flickering or problem. – Hovercraft Full Of Eels Feb 21 '12 at 22:15
  • 2
    Before you go to the effort of rewriting your app, please consider this essay: [How do I create a topmost window that is never covered by other topmost windows?](http://blogs.msdn.com/b/oldnewthing/archive/2011/03/10/10138969.aspx) – Greg Hewgill Feb 21 '12 at 22:15
  • Please write why downvote, people please? – deadfish Feb 21 '12 at 22:21
  • I'm using a Thread that update setAlwaysOnTop() of my frame every 200ms. – Dan Bradbury Feb 21 '12 at 22:23
  • 2
    @Dan: What do you mean by "using a Thread that update setAlwaysOnTop..."? Do you mean to say that you're calling this method every 200 ms? If so, this is totally unnecessary -- you just need to call it once. Consider posting code, consider getting rid of all those C, C++, and C# tags as they're nothing but clutter. – Hovercraft Full Of Eels Feb 21 '12 at 22:25
  • possible duplicate of ["Always on Top" Windows with Java](http://stackoverflow.com/questions/297938/always-on-top-windows-with-java) – Tony Feb 21 '12 at 22:34
  • 1
    @HovercraftFullOfEels the fullscreen application will take precedence some time and then will become the top most element. When this happens the thread will update and allow my program to always be on time. What I didn't do what do a frame.repaint() when I did that everything worked out fine. Thanks All Sorry for the bad tagging – Dan Bradbury Feb 21 '12 at 22:37
  • Not your down voter and in fact I up-voted you for your post above giving more details and your solution. – Hovercraft Full Of Eels Feb 21 '12 at 22:39

1 Answers1

1

Short answer: Not really, no.

Longer answer: A "full-screen" app uses the display in a different way than a normal Windows GUI app. Exactly how they work depends on the application and the OS; most will leverage the DirectX or OpenGL APIs which allow applications to directly manipulate the memory representing the screen, as well as access the accelerated capabilities of the GPU. These apps are supported by basically creating a GUI "window" (more like a panel) that covers the entire primary display and is "always on top", preventing the desktop elements from ever being painted as they're always behind the full-screen app's window in the Z-order. The application then gets "relaxed" access to the memory representing the display rectangle of that GUI window, so it can manipulate individual pixels without needing to use the message loop to repaint that area.

In this situation, the display is being painted when the application wants (which is virtually always either "as fast as possible" or "synchronized with the next monitor scan"), NOT when the Windows GUI thinks it's a good time. So, anything that IS painted when Windows thinks it's a good idea will flicker; Windows paints your "always on top" window over the app's "window" in the GUI's Z-order, then the app paints back over the window by drawing directly onto its rectangle. That causes Windows to invalidate and redraw your window, and the cycle continues.

The solution is not only to make an "always-on-top" window, but to somehow programmatically "task-switch" from the full-screen app's window to yours. This may require your app to have privileges that most managed runtimes can't or won't grant. If it's possible, then when it happens the full-screen app will minimize (which may or may not be a HUGE problem for your users; whatever your app is trying to tell me, it will almost certainly NOT be worth minimizing my StarCraft 2 session in the middle of an online melee).

KeithS
  • 70,210
  • 21
  • 112
  • 164
  • keith thanks for response. Really good one. I have got my application to work but like you said there is that annoying switching between tasks. If this is not possible to do since the fullscreen app utilizes the GPU and all the priorities. Is there a solution that hacks and other things use to use manipulate an active program without the task switching? – Dan Bradbury Feb 22 '12 at 01:52
  • 1
    Probably not. The only way your app's window would show on top of another full-screen app's display without flicker is if the full-screen app uses the message loop to signal draws, and by so doing obeys the Z-order of windows on the desktop. Certain applications that don't require extremely high framerates may do this in order to simplify their display in a "windowed" mode (because they obey the Z-order whether they're full-screen or not, the drawing logic is identical). Most apps, though, try to maximize framerate, and that means largely ignoring the message loop and Z-order. – KeithS Feb 22 '12 at 22:45
  • Keith, you are just dropping knowledge bombs all over me. I have noticed that if I start trying to compete for the top window with an application such as a game the frame rate of the game drastically decreases. Is this something to do with the cycle being interrupted or my application not giving the game what it wants (to be on top)? Ps when you say probably not it gives me some hope that I will be able to find some sort of solution. I'll keep looking and see what some hacks do to stay on top/ manipulate the program they are attached to. – Dan Bradbury Feb 22 '12 at 23:15