Qt/OpenGL: drawing into non-exposed windows - windows

I am using gitlab-ci-runner to automatically test a desktop Qt/OpenGL application on every commit. On Windows 8, the application is executed by a system service installed with gitlab-ci-runner, hence it is run "hidden", i.e. on no visible desktop. All the UI modules initialize and run anyway, except the OpenGL module, which never gets an "expose" event; if I try to draw into the OpenGL context without the window being exposed I get the error:
QOpenGLContext::swapBuffers() called with non-exposed window, behavior is undefined
I have found out that it is rather difficult and not recommended to execute a Windows GUI application from a service on a running desktop session (see How can a Windows service execute a GUI application?).
Now, I don't need the user to see the application, I just need the OpenGL part to work correctly. Is there a way I can "pretend" to expose a window somehow, or is there any other way to get this to run correctly from a system service?

Is there a way I can "pretend" to expose a window somehow, or is there any other way to get this to run correctly from a system service?
Two problems you're running into:
If a window is not exposed all pixels rendered to will fail the pixel ownership test and rendering turns into a NoOp for all the pixels. The workaround for that is using wither a PBuffer or (recommended) a framebuffer object. Neither will immediately work with a on screen window, so you'll have to change some code.
In Windows processes started as a service usually don't get access to the graphics hardware, so you're limited to the capabilities of the software GDI OpenGL fallback (limited to OpenGL-1.1, hence no support for FBOs or PBuffers).
If you need GPU acceleration you can either invest into some grid computing GPU hardware (well, actually every GPU could do it, but the drivers disallow it for consumer grade stuff) to get a working OpenGL accelerated context. Or you can migrate to Linux, use a GPU supported by KMS/DRI/DRM and completely circumvent any graphics system. There's no official guide on how to do that, but it's on my (lengthy) ToDo list writing such a tutorial.
If you can live without GPU acceleration, drop a Windows build of Mesa with the softpipe renderer beside your program's .exe; the Windows Mesa softpipe build comes as a opengl32.dll fully API and ABI compatible with the standard opengl32.dll, but is independent of any graphics driver. It gives you OpenGL-3.3 support including FBOs and PBuffers.

Related

Rapid desktop screen capture on Windows

I want to capture the desktop screen image on Windows.
I know about the CreateCompatibleDC and CreateCompatibleBitmap... functions in C++ but it they are very slow. I need a more rapid method that does a screen capture suitable for real-time updates. In Linux I could use Xlib functions, for example. Are there any similar high-speed or system-level screencap functions for Windows?
For Windows 8 (and later) there is native API: Desktop Duplication API
For Windows 7 (and earlier) you may consider using a mirror driver. For example, the DFMirage driver

How to use DirectX 9 with multi- GPU on windows7

I‘ve got multiple nVidia GPU Cards (Q2000) on a Windows 7 system,without SLI, only one monitor.
Now what I'm trying to do is make a Direct3D9 device runing on a specific GPU.
I can use the [Adapter] parameter in IDirect3D9::CreateDevice to choose a GPU, but unless I connect a second monitor on that GPU card, it will not work (if I've only got one desktop on Windows).
If I click the "Detect" button in Resolution Control Panel, it can make a "fake" desktop on the side of my primary desktop, and CreateDevice(1, ...) works well - but this is not what I want.
For OpenGL, it's easy because the WGL_NV_gpu_affinity, It can make a OpenGL device runs on the second GPU with only one monitor connected, one desktop on windows.
I wonder if there is any API can use for Directx 9 work as "WGL_NV_gpu_affinity".
Any hint will be very appreciated. Thanks in advance!
IDirect3D9::CreateDevice uses at 1st parametr "Adapter", which not GPU, just monitor adapter

Monitor process resources on Windows CE 5.0

I'm developing a WinCE 5.0 application that uses two commercial libraries. When the application starts calling the second library it gets slowlier and then after some use, it hangs and the whole OS freezes. It has to be rebooted to work again. The thing is that I'm developing this without a physical device (a testing person installs each release and runs the tests) and without an emulator (the device provider is not facilitating an OS image).
My intuition tells me that the second library is using all the available resources (basically, handles and memory) for a WinCE 5.0 process. I have to prove this to the library vendor. So I wish to add to my logs some general process and system information. Could you recommend me which APIs to call to get this information in CE?
I would really appreciate any hint
Thanks in advance!
Windows CE provides a very robust set of APIs for a subsystem called CeLog. CeLog is what Kernel Tracker uses to collect and display it's information. You can get all the way down to scheduler calls and thread migrations if you want. The real danger with using CeLog is in collecting too much data so that making sense of it is difficult, but if you filter the collections to just your process, that should help. You could collect the data to a log file, then use Kernel Tracker to open and view that data.
Here are some good starting points for info:
Introduction to Remote Kernel Tracker
More on Remote Kernel Tracker
CeLogFlush.exe (particularly the section 'Collecting Data on a Standalone Device with CeLogFlush')
Implementing a Custom Event Tracking Library
Embedded Visual C++ 4 contained "Remote Performance Monitor" that could do just that. Microsoft retracted EVC4 as free download some time ago, but it can still be downloaded from MSDN or found on the internet.
With service pack 4 it should work for WinCE 5.0. It does not appear to work with Windows Embedded 6.0 and newer though.

Create virtual hardware, kernel, qemu for Android Emulator in order to produce OpenGL graphics

I am new to android and wish to play around with the emulator.
What I want to do is to create my own piece of virtual hardware that can collect OpenGL commands and produce OpenGL graphics.
I have been told that in order to do this I will need to write a linux kernal driver to enable communication with the hardware. Additionally, I will need to write an Android user space library to call the kernal driver.
To start with I plan on making a very simple piece of hardware that only does, say 1 or 2, commands.
Has anyone here done something like this? If so, do you have any tips or possible links to extra information?
Any feedback would be appreciated.
Writing a hardware emulation is a tricky task and by no means easy. So if you really want to do this, I'd not start from scratch. In your case I'd first start with some simpler (because many of the libraries are already in place on guest and the host side): Implementing a OpenGL passthrough for ordinary Linux through qemu. What does it take:
First you add some virtual GPU into qemu, which also involves adding a new graphics output module that uses OpenGL (so far qemu uses SDL). Next you create DRI/DRM drivers in the Linux kernel, that will run on the guest (Android uses its own graphics system, but for learning DRI/DRM are fine), as well as in Mesa. On the host side you must translate what comes from qemu in OpenGL calls. Since the host side GPU is doing all the hard work your DRI/DRM part will be quite minimal and just build a brigde.
The emulator that comes with Android SDK 23 already runs OpenGL, you can try this out with the official MoreTeapots example: https://github.com/googlesamples/android-ndk/tree/a5fdebebdb27ea29cb8a96e08e1ed8c796fa52db/MoreTeapots
I am pretty sure that it is hardware accelerated, since all those polygons are rendering at 60 FPS.
The AVD creation GUI from Studio has a hardware acceleration option, which should control options like:
==> config.ini <==
hw.gpu.enabled=yes
hw.gpu.mode=auto
==> hardware-qemu.ini <==
hw.gpu.enabled = true
hw.gpu.mode = host
hw.gpu.blacklisted = no
in ~/.android/avd/Nexus_One_API_24.a/.

How to emulate/replace/re-enable classical Sound Mixer controls (or commands) in Windows Vista?

I have a problem (and have been having it for some time now) -- the new sound mixer stack in Vista features new cool things, but also re-invents the wheel. Many applications that used to use Volume Mixer on a Windows system to mix different voiced outputs into one input (for example Wave-out + Line-in --> Stereo Mix) have since stopped working. The prime example of this behavior is the Shoutcast DSP plugin (could be useful for solution testing).
How Can I re-enable XP-mixer controls, or maybe emulate this behavior somehow, so that the program (SC DSP) can properly manage Microphone/Line-In playback volume along with Wave-out playback volume?
My thinking would be to emulate a program hooked-in into the Vista Mixer for Wave-Out and Line-out (or Mic speaker volume -- all playback, shown as separate adjustable "programs" so that the Vista Mixer could refer to it) and 'hook' it into the system under some emulation representing itself as the old volume mixer control interface for the program, but I frankly have no idea how to do that.
To clarify: this is not my PC (it is a HP Pavilion laptop). The problem seems to exist mostly due to the fact that Vista mixer controls separate programs, not separate inputs/outputs. The hardware is fully capable of doing what is needed when using Windows XP. I am well aware of the fact that this is a driver issue, but the driver is simply prepared for what Vista presents to the programmer through interfaces. The mixer device - as seen in the operating system, however it might look in software - is based on the mixer APIs for Windows Audio control.
Search using Google on Vista and line-in playback volume control for more info on the problem (and the sheer amount of users affected by it). Of course, a re-write of the Shoutcast Source DSP plug-in for WinAMP would do the trick, but that is not likely to happen...
Controlling the volume levels of a soundcards indivudual input/output levels in Windows Vista mixer is possible using the audio EndPoint API
This should allow you to adjust the main volume, and the volume of and connected audio inputs. One wrinkle about this that when you enumerate the end points, if there isn't a microphone plugged into your soundcard, then nothing will be enumerated. This means you'll need to change your application to respond to "microphone plugged in" events, and notify the user appropriately.
Another option is to dip below the Microsoft Core Audio and access the WaveRT driver directly. This is a lot more work than using the WASAPI/Endpoint APIs, but will give you the most control over access to the inputs/outputs of the soundcard.
The audio driver controls which mixer controls are available, and this will depend largely on the capabilities of the hardware.
If the Vista driver doesn't have certain controls, then it's likely to be a shortcoming of that driver and not of Vista.
(Please tell us which sound card/device you are using.)
It would be possible to write a program to create your own mixer controls (this would be a software-only driver for a virtual sound card), but this program wouldn't be able to affect the audio routing inside the device if the actual driver doesn't have some mixer control for this.
If you mark your app as running in Windows XP compatibility, then all the old controls and behaviors will come back.
If you mark your app as running in Windows XP compatibility, then all the old controls and behaviors will come back.
This is true, but as of Vista SP1 patch KB957388, included in SP2, and with some soundcard drivers, the old mixer API (winmm.dll) functions can hang when the app is in XP compatibility mode. In particular, mixerGetNumDevs and less often mixerOpen will not return on some computers.
I've got reports from 5 Vista users out of around 200 Vista users in total where my app hangs when starting up, and I have tracked it down to these functions hanging.
I would like to report this to Microsoft but cannot find anywhere to do so.
All I can do now is release my software without compatibility mode enabled, but this loses functionality in my app, and the software cannot control the line-in or microphone mixers.
I don't have time to work with low level API functions directly. I rely on high level components, and I cannot find any for the new audio API's for my development system (Delphi).
I would be interested in paying someone to write a DLL for me!!!
e mail ross att stationplaylist dott com

Resources