I have created an animation in C++ using OpenGL and SDL (it uses no Windows libraries) and wish to use it as a screen saver for a Windows system. I read one example: it describes that you simply have to change the .exe extension to .scr.
I have done that and ran the animation as a screen saver but I noticed that the animation did not run smoothly at all. As if there was a loss in the application performance.
The application I made creates the animation, sets it to full screen, hides the cursor and handles all keyboard input. How can I make my application run smoothly as a screen saver?
It's more than just renaming the file.
At the bare minimum you must support correct behavior in response to the following command line parameters (taken from Microsoft):
ScreenSaver - Show the Settings dialog box.
ScreenSaver /c - Show the Settings dialog box, modal to the
foreground window.
ScreenSaver /p <HWND> - Preview Screen Saver as child of window <HWND>.
ScreenSaver /s - Run the Screen Saver.
If multiple instances of your executable are being started and run as a full screen screen saver (the screen saver should only actually run if /s is specified), that may be the cause of your performance issues. You should verify that in e.g. Task Manager.
Hope that helps.
Related
I have the following setup for the game:
launcher.exe - starts under Steam on Windows and provides some settings UI for the user.
Then launcher.exe starts actual game.exe.
Problem is that the launcher.exe is using H/W accelerated UI - uses Direct2D/DirectX.
This page https://partner.steamgames.com/doc/features/overlay states:
Your game does not need to do anything special for the overlay to
work, it automatically hooks into any game launched from Steam!
But in my case that creates problems - the overlay is created on wrong window. So launcher.exe (uses DirectX) has the overlay but window that is created by game.exe (real game, uses DirectX and/or OpenGL) is not.
And the question is: how can I modify code of my launcher.exe window to prevent Steam overlay to be created on it "automatically"?
Update, response from Valve's TS:
Sorry, there's no code in place to selectively enable or disable the
overlay between launchers and games!
The only "option" is to disable DirectX drawing in the launcher.exe. In this case their injected DLL will not create that thing. But that effectively means no GPU accelerated UI drawing under the Steam... Kind of "640kb is enough for everybody" type of design.
Ideally Steam should send some custom message to the window to ask how and where the window wants that overlay to be rendered. But apparently there is no such thing, or is it?
Just for the context, the launcher looks as this:
I'm developing a 3D desktop application like this where I duplicate the desktop by creating planes in 3D space using each window's bitmap as texture and then passing mouse and keyboard input to them (background windows) via windows API.
This approach causes several issues and the main one is that some clicked windows generate new popup windows like menus that popup on top of 3D app and steal focus.
Is it possible to properly duplicate a desktop behavior inside another app like this - without losing focus and keeping 3D app on top?
Only workaround for this that I can think of is to have 3D app running on secondary monitor, let user work with regular desktop on primary monitor as usual and 3D app will just duplicate that and use windows hooks for any 3D app specific input.
Apparently IInspectable is right. No reliable way to do this without losing focus.
I've developed a Qt/QML application which I display with a translucent QDeclarativeView in a translucent frameless QMainWindow (see this). The application is fairly complex with a a few ListViews inside and some threads that poll a remote server for data and feed the views. The program runs flawlessly and at full speed without glitches on Windows 7. But when I compile and run it on Snow Leopard I've got the following problems;
GUI rendering is slow in general
When I scroll the ListView with the mouse wheel, the wheel actions affect the underlying window and my GUI flickers as if it can't render fast enough. Also often when I click something on my GUI, the mouse click just passes through my window onto the underlying window and brings it in front.
Mouse actions feel awkward. There is a significant delay.
These problems are present on both the Release and Debug builds with/without gdb attached.
The problems sound related to me but I'm confused. Why would an application running perfectly on Win7 perform badly on Snow Leopard ? Am I missing some specific configuration ?
I'm using Qt 4.6.3, and ubuntu linux on an embedded target. I call
dlg->setWindowState(Qt::WindowFullScreen);
on my windows in my application (so I don't loose any real-estate on the touch screen to task bar and status panel on the top and bottom of the screen. This all works fine and as expected. The issue comes in when I want to popup the on screen keyboard to allow the user to input some data. I use
m_keyProc= new QProcess();
m_keyProc->start("onboard -s 640x120");
This pops up the keyboard but it is behind the full screen window. The onbaord keyboards preferences are set such that it is always on top, but that seems to actually mean "except for full screen windows". I guess that makes sense and probably meets most use cases, but I need it to be really on top.
Can I either A) Not be full screen mode (so the keyboard works) and programmatically hide the task bars? or B) Force the keyboard to be on top despite my full screen status?
Note: On windows we call
m_keyProc->start("C:\\Windows\\system32\\osk.exe");
and the osk keyboard is on top despite the full screen status. So, I'm guessing this is a difference in window mangers on the different operating systems. So do I need to set some flag on the window with the linux window manager?
Qt doesn't seem to have a way to bring other, non-Qt process in front. You may need to get the native, platform process ID from QProcess by calling QProcess::pid() and call the underlying OS API to do it.
I've seen an application that simulates a fullscreen application by removing the title bar and the window borders. I've done some research and found getWindowLongPtr() for that.
Now my question: How can I find and identify the application and get the appropriate window handle? How can I distinguish multiple instances of the application (running from different locations on disc)?
Just to make "simulate" more precise. If you make an application go fullscreen and you click on a different monitor, it minimizes itself. If the application runs in a window and you click on a different monitor, the window is not changed. If you remove the borders of the window and position it on the left or right monitor, you can still work with the other monitor without minimizing the application. Still it looks like the application running fullscreen on one of the monitors.
As an example: you can set Eve (www.eveonline.com) to fullscreen and windowed mode. In fullscreenmode you can not click on a second monitor without Eve minimizing itself. In window mode you can. There are tools like evemover that allow you to setup your window on one monitor, looking like fullscreen, but being in window mode. That's what I want to archieve. Evemover actually provides some of it's source code, that's why I know that removing the border and setting the position is done using the Win32-API with setWindowLongPtr and setWindowPos.
Many applications use divergent and confusing applications of the phrase "fullscreen".
A fullscreen application simply - occupies the full screen area.
DirectX applications can request a fullscreen exclusive mode. The advantage of this mode to DirectX applications is, with exclusive access to the (full) screen they are then allowed to change the resolution, bit depth etc, as well as gain access to vertical sync synchronized hardware buffering where the screen surface is 'flipped' between display intervals so that 'tearing' does not occur.
Anyway, the windows desktop understands 'fullscreen windows' - windows that occupy the full area of a monitor and have no non client elements. When windows like this are created, things like desktop gadgets and task bars automatically hide themselves. Modern games have come to call this mode 'fullscreen windowed'.
Back to your question: 'FindWindow' is the API used to discover other applications windows. Getting the path to the application that created the window is much harder. GetWindowThreadProcessId can get you the process id of the owning process. OpenProcess will get you a handle that you can pass to QueryFullProcessImageName (implemented on Vista and above) to get the full path to the process.
I think you are refering to applications like window aggregators, that 'plug in' to the system and act from outside the application.
Look at the code for the freeware app PuttyCM (for aggregating Putty (SSH) shell windows as tabs). IIRC, it ensures that the Window pointer passed to the application has the flags already set.
On applications running from different places, you will probably need some way of identifying it - registry entries / install log etc.