Programmatically Disable Video Acceleration

Yeah, basically creating a video of the screen. I'm not using DirectX, just standard GDI functions:

//get the device context for the desktop
HDC dc = GetDC(NULL);

//create a dc compatible with the desktop
HDC mDc = CreateCompatibleDC(dc);

//create a bitmap compatible with desktop of desired size width, height
HBITMAP hbm = CreateCompatibleBitmap(dc, width, height);

//select the bitmap on the memory device context
SelectObject(mDc, hbm);

//BitBlt the image from the desktop onto the bitmap
//BitBlt(mDc, 0, 0, width, height, dc, 0, 0, SRCCOPY);

and then later I call GetDIBits to retrieve the actual bitmap information (in the same format, no colourspace conversion).

This process involves reading from video ram, where some drivers are heavily optimised towards writing to video ram only. So the video driver spends a long time reading, and i'm guessing that while this takes place no other video functions can be invoked, which effectively 'pauses' the screen, including pointer movement. Only seems to happen on crappy (even some new!) hardware (i'm looking at YOU S3! :) ).

Disabling the video acceleration in the troubleshooting section of the advanced display settings, I think, effectively disables the invocation of GDI and 3D accelerations the driver/card may perform and the windows software implementation performs it all, which solves the 'jerky mouse' problem for those who experience it.

What I want to be able to do is programatically change that setting, rather than ask users to do so ...

uh, and the BitBlt(mDc, 0, 0, width, height, dc, 0, 0, SRCCOPY); shouldn't be commented out :P

That code you are using is the most efficient if you use WinAPI. I suggest doing some direct memory access. This can be done with either DirectX or some kernel mode driver which can read physical memory, and AFTER you read all the memory, when the capturing has finished, THEN reconstruct it to bitmap.

Reading physical memory and interpretting it is tough and requires different handling for different video modes. I suggest you use DirectX .

Wouldn't the DirectX code ultimately rely on the video card driver in the end anyway ? I mean, the screen buffer is physically stored on the RAM on the video board .. and if the driver is weak in being able to read from this memory we are back where we started.

Also, at the end of the day I can't justify requiring users to install directx when all the needed functionality is supplied by standard gdi. The same goes for a driver, with the added disadvantage of having to write separate 9x and NT drivers .. not really feasible to do this much work just to help out a few people with cheap video cards.

Besides, the current level of performance is fine. It's only when used in conjunction with poor video hardware is there a problem, and this is easily remedied by manually disabling the video 'acceleration' of poor hardware.

All I need to do, is progammatically disable/restore the hardware acceleration. The display properties applet does it, so it must be possible .. and another app claims to be able to do it.

http://www.geocities.com/nickrepin/winprog.html#disphardwaccel

Thanks for the link NickRepin -- sorry for the delay i've (involutarily) been offline for a few days ... i'll check out that code now and post my finding (specifically whether it works for NT family too)

The code doesn't seem to change the setting i'm after in XP (right-click desktop->properties->settings->advanced->troubleshoot->slider bar). Normally when you change this setting the screen will go blank for a couple of seconds .. I dont currently have access to a 9x family machine to test it for 9x purposes, but will test when I get my hands on one ...

Still looking for an NT solution ..

Mate, thank you for that. I LOVE solutions that adhere to the KISS principle! Just break it into a number of system calls! beautiful!

Thanks. :)