I have written a screen capture program using windows screen capture API in DXGI。It works just OK。
But on some cases (such as when I drag a window to move it), the result contains a cursor shape on it.
]
This is not what I expected.
Does ayone know how can I do to get rid of that.
As far as i know there is no way to prevent this within DXGI. Your graphics adapter will decide wether to draw the cursor seperatly (you have to do the drawing yourself) or directly in to the screen image.
So basically your options are:
Write your own graphics adapter
Check if the cursor is invisible with FrameInfo->PointerPosition.Visible (that means the cursor is already drawn in the frame) and replace the cursor region with a previously saved frame -> overdraw it
Select a fully transparent cursor
Related
I am coding little fun gadget. I want to be able to draw second (or more) mouse pointer icons at different location than the original mouse but to move it according to move of original mouse.
I know how to track movement of the mouse but I dunno how to draw/redraw mouse pointer; can anyone help?
You can use the following code:
CURSORINFO ci;
ci.cbSize = sizeof(CURSORINFO);
GetCursorInfo(&ci);
Next you can draw a cursor by calling:
DrawIcon(ContextDC, YourXPosition, YourYPosition, ci.hCursor);
If you need additional information about the cursor, like hotspot for example, check the ICONINFO structure:
ICONINFO ii;
GetIconInfo(ci.hCursor, &ii);
This could be done like:
grab the current mouse cursor from your application, using LoadCursor(). Just specify NULL, and the cursor you want. Or just load a bitmap for the cursor. Now, you have a bitmap.
Next step is to get the Device context of your Desktop: GetWindowDC(NULL). This will give you the opportunity to draw on the desktop anywhere.
There is a huge chance that you will need to apply CreateCompatibleBitmap() to the Image at #1 with the DC obtained at #2.
Now, use some BitBlt() to copy bits OUT from the DC obtained at #2 into a save image (YOU will need to create these) from the position you want to put your cursor.
Now, put the image obtained at #3 onto the DC of the Desktop obtained at #2 at the position you want.
When the user moved the mouse restore the image on the desktop with the saved data at #4. Release all the stuff you don't need (yes, this is mandatory).
And restart from #1.
These two more links might help:
Bitmaps, Device Contexts and BitBlt
Capturing an Image
Good luck!
I am haveing trouble understanding the concept of the UpdateLayaredWindow api, how it works and how to implement it. Say for example I want to override CFrameWnd and draw a custom, alpha blended frame with UpdateLayeredWindow, as I understand it, the only way to draw child controls is to either: Blend them to the frame's Bitmap buffer (Created with CreateCompatibleBitmap) and redraw the whole frame, or create another window that sits ontop of the layered frame and draws child controls regularly (which defeats the whole idea of layered windows, because the window region wouldn't update anyway).
If I use the first method, the whole frame is redrawn - surely this is inpractical for a large application..? Or is it that the frame is constantly updated anyway so modifying the bitmap buffer wouldn't cause extra redrawing.
An example of a window similar to what I would like to achieve is the Skype notification box/incoming call box. A translucent frame/window with child contorls sitting ontop, that you can move around the screen.
In a practical, commercial world, how do I do it? Please don't refer me to the documentation, I know what it says; I need someone to explain practical methods of the infrastructure I should use to implement this.
Thanks.
It is very unclear exactly what aspect of layered windows gives you a problem, I'll just noodle on about how they are implemented and explaining their limitations from that.
Layered windows are implemented by using a hardware feature of the video adapter called "layers". The adapter has the basic ability to combine the pixels from distinct chunks of video memory, mixing them before sending them to the monitor. Obvious examples of that are the mouse cursor, it gets super-imposed on the pixels of the desktop frame buffer so it doesn't take a lot of effort to animate it when you move the mouse. Or the overlay used to display a video, the video stream decoder writes the video pixels directly to a separate frame buffer. Or the shadow cast by the frame of a toplevel window on top of the windows behind it.
The video adapter allows a few simple logical operations on the two pixel values when combining their values. The first one is an obvious one, the mixing operation that lets some of the pixel value overlap the background pixel. That effect provides opacity, you can see the background partially behind the window.
The second one is color-keying, the kind of effect you see used when the weather man on TV stands in front of a weather map. He actually stands in front of a green screen, the camera mixing panel filters out the green and replaces it with the pixels from the weather map. That effect provides pure transparency.
You see this back in the arguments passed to UpdateLayeredWindow(), the function you must call in your code to setup the layered window. The dwFlags argument select the basic operations supported by the video hardware, ULW_ALPHA flag enables the opacity effect, the ULW_COLORKEY flag enables the transparency effect. The transparency effect requires the color key, that's specified with the crKey argument value. The opacity effect is controlled with the pblend argument. This one is built for future expansion, one that hasn't happened yet. The only interesting field in the BLENDFUNCTION struct is SourceConstantAlpha, it controls the amount of opacity.
So a basic effect available for a layered window is opacity, overlapping the background windows and leaving the partially visible. One restriction to that the entire window is partially opaque, including the border and the title bar. That doesn't look good, you typically want to create a borderless window and take on the burden of creating your own window frame. Requires a bunch of code btw.
And a basic effect is transparency, completely hiding parts of a window. You often want to combine the two effects and that requires two layered windows. One that provides the partial opacity, another on top and owned by the bottom one that displays the parts of the window that are opaque, like the controls. Using the color key to make its background transparent and make the the bottom window visible.
Beyond this, another important feature for custom windows is enabled by SetWindowRgn(). It lets you give the window a shape other than a rectangle. Again it is important to omit the border and title bar, they don't work on a shaped window. The programming effort is to combine these features in a tasteful way that isn't too grossly different from the look-and-feel of windows created by other applications and write the code that paints the replacement window parts and still makes the window functional like a regular window. Things like resizing and moving the window for example, you typically do so by custom handling the WM_NCHITTEST message.
I'm trying to draw on the screen (the whole screen, on top of every other window) using GDI+.
I've passed NULL to GetDC to get a HDC to the screen, and then used that to create a Graphics object, and used DrawRectangle to draw rectangles on the screen.
Everything works..except...the inside of the rectangle won't update.
Like if I draw it over a command prompt, and move the command prompt, the inside of the rectangle remains black.
I expect to see whats under the rectangle.
Here's the code that's doing the drawing..
Pen BluePen(Color(255, 0, 255, 0), 2);
Graphics graphics(screenDC);
graphics.DrawRectangle(&BluePen, myRect);
Pretty simple, so is there something I have to do to get the inside of the rectangle to update when the screen does? Or to get it truely transparent.
================= EDIT =================
Well I had given up on this, and assumed it wasn't possible, until...I realized the Inspect tool that comes with the Windows SDK does this perfectly.
I would like to recreate something similar to the highlight rectangle, and if I select a window (such as Firefox) and then bring Inspect into focus I can move it around freely with everything being updated perfectly.
There's not even any flickering.
So...does anyone know how Inspect manages to do this?
Also answers in GDI instead of GDI+ are fine...
In windows the screen (and the windows ...) surface(s) are ... volatile, like sandboxes. The "overlapping" of windows and the re-painting of uncovered surfaces is an illusion made by proper event management.
Everything is drawn remain there until something else is drawn over it.
"Uncovering" a surface makes the window representing that surface to receive a WM_PAINT message. It's up to that window procedure to react to that message by re-painting everything is supposed to be under it.
Now, unless you intercept somehow the WM_PAINT message that is sent to the desktop window, you have mostly no chance to know the desktop needs a repaint and hence your paint code will not be called and no repaint will happen. Or better it happens following just the desktop window updating code, that's not aware of your paint.
I want to have a red line instead of mouse pointer in my (written in C++ with OpenGL) application. For example when I move the mouse over an OpenGL window, I would like the cursor to become a red line. How can I do that?
Also, how can I call the mouse related functions (OpenGL) for that line and specify the functionality?
As Nicol Bolas said in his comment, OpenGL knows nothing of the mouse. You'll need to interact with the windowing system one way or another (via direct Win32/X11/etc. API or via a portable windowing library a la Qt, wxWidgets, etc) to monitor mouse position.
If the cursor you're trying to draw is a bitmap, your best bet is likely to handle mouse enter/leave events sent to your window and respond to them by using an API function to change the cursor. This will handle automatically updating the cursor as the mouse moves around and will add minimal overhead to your application (windowing system cursors generally draw in an overlay plane that avoids sending redraw events to your window every time the mouse moves).
If you have a more procedural description of your cursor (that is, you intend to draw it with OpenGL drawing commands), you'll instead want to handle the mouse enter/leave events by using HideCursor()/ShowCursor() commands or the equivalent to turn off the windowing system's native cursor when the mouse is over your window. Then, you'll hook the mouse move callbacks and redraw your scene, adding whatever commands you need to draw the cursor at the position specified in the mouse move event.
The first approach is definitely preferred for performance & latency reasons--but there are some cursor types (think full screen crosshairs) that can't be accomodated that way.
I'm creating a non-intrusive popup window to notify the user when processing a time-consuming operation. At the moment I'm setting its transparency by calling SetLayeredWindowAttributes which gives me a reasonable result:
alt text http://img6.imageshack.us/img6/3144/transparentn.jpg
However I'd like the text and close button to appear opaque (it doesn't quite look right with white text) while keeping the background transparent - is there a way of doing this?
In order to do "proper" alpha in a layered window you need to supply the window manager with a PARGB bitmap by a call to UpdateLayeredWindow.
The cleanest way to achieve this that I know of is the following:
Create a GDI+ Bitmap object with the PixelFormat32bppPARGB pixel format.
Create a Graphics object to draw in this Bitmap object.
Do all your drawing into this object using GDI+.
Destroy the Graphics object created in step 2.
Call the GetHBITMAP method on the Bitmap object to get a Windows HBITMAP.
Destroy the Bitmap object.
Create a memory DC using CreateCompatibleDC and select the HBITMAP from step 5 into it.
Call UpdateLayeredWindow using the memory DC as a source.
Select previous bitmap and delete the memory DC.
Destroy the HBITMAP created in step 5.
This method should allow you to control the alpha channel of everything that is drawn: transparent for the background, opaque for the text and button.
Also, since you are going to be outputting text, I recommend that you call SystemParametersInfo to get the default antialiasing setting (SPI_GETFONTSMOOTHING), and then the SetTextRenderingHint on the Graphics object to set the antialiasing type to the same type that is configured by the user, for a nicer look.
I suspect you'll need two top level windows rather than one - one that has the alpha blend and a second that is display above the first with the opaque text and button but with a transparent background. To accomplish this with a single window you'll need to use the UpdateLayeredWindow API call, but using this will cause your buttons to not redraw when they are interacted with (hover highlights, focus etc.)
It is possible that if this application is for Vista only there is a new API call that you can use, but I do not believe it is available in XP or earlier.
I can't say for sure, you'll need to try it, but since everything is a window, you could try setting the layered attributes for your button to make it opaque.
As for the text, you may be able to put that in its own frame with a set background and foreground color, and modify its layered attributes to make the background color transparent...
But since these are child windows and not the top-level window, I really don't know that it'll work.