This should be a simple google or MSDN answer - but I have come up short in searching. I have a small win32 application that uses GDI for a lot of drawing. I have observed that when I place a "label" with TextOut() on my memory Device Context, then BitBlt immediately after the TextOut() call, the text shows up intermittently, flickering in and out. The BitBlt() is in another thread, but I have a critical section to guard from copying the graphic under work. When I put the TextOut() earlier in the flow, i.e. not close to the BitBlt(), it always shows up. All I can figure is that TextOut() returns before completion.. can anyone point me to documentation or suggest another theory?
FYI - I have already checked out:
http://msdn.microsoft.com/en-us/library/dd145133(v=vs.85).aspx
Thanks!
Yes it does. GdiFlush() is the call to force all GDI updates to the video adapter.
Lots of other ways to shoot your foot. GDI is not thread-safe at all so don't expect miracles, I guess.
Related
I'm making a program to record a window that is obscured by another window via python and WIN32API library.
Through many searches, I succeeded in capturing the hidden window through hwnd and BitBlt, but the execution time of my code is not stable.
I tried to provide the recording function by selecting 30~60 fps, but the time required to capture the hidden window and write() it to the video object of cv2 is irregular, so I can't make a 60fps video.
So I thought of OBS and Discord. In the case of OBS, it is possible to enforce stable recording for obscured windows. For Discord, there is a feature that allows you to select a specific window and share it with multiple people in real time (this can also be done for hidden windows).
I'd like to know how these programs provide stable video for occluded windows. I'm a student, and I'm not elite. I am asking this question because it is difficult to analyze the vast Github source code of OBS. Can someone give me an explanation of how the above program captures the screen?
Last time I checked, OBS was doing it with low-level hacks instead of APIs.
Specifically, they have wrote a DLL which they inject into the target application using CreateRemoteThread WinAPI. Then, they patch application’s code to intercept calls to IDXGISwapChain.Present method. Once a call is intercepted, the injected code has access to D3D frame buffer texture. It can copy that texture into another texture on GPU, and then do something with the copy. One possibility is DXGI surface sharing to pass the copy from the target application into the capturing process. The APIs for that don’t require both sides of the sharing to be in the same process, textures can be shared across processes just fine.
Unfortunately for you, their approach is borderline impossible to re-implement in higher-level languages like Python. Such things are only doable in C++ or similar low-level languages, and relatively hard to implement and debug.
#dy.kim, don't be afraid of large codebases. window-capture.c and the OBS GUI fairly obviously list "bitblt" and "Windows Graphics Capture" as the two methods it uses to capture windows, with the preference going to WGC if neither is specified.
I have an existing component that draws Direct2D content to an ID2D1RenderTarget and I would like to save that drawing to an image file. The questions here, here and here, although they helped me, did not provide a clear answer as how to do it.
My nullth idea was to try the official MSDN method. Unfortunately, it is not available in Win7.
My first idea was to modify the drawing routine to make it accept the RenderTarget as a parameter and use ID2D1Factory::CreateWicBitmapRenderTarget to draw directly into a IWICBitmap, but it turns out to be quite difficult for me (because it would be necessary to modify not only the drawing routine itself, but also the drawing callbacks of all users of that component (the code, written in Delphi, uses Embarcadero's TDirect2DCanvas, and thus did not need to manage all Direct2D resources, like render target or brushes)).
My second idea was to create an ID2D1Bitmap, fill it with what is already drawn using ID2D1Bitmap::CopyFromRenderTarget and then draw that ID2D1Bitmap to a WicBitmapRenderTarget (this is about what was done here). I had the same kind of problems as those who asked the questions I link to: different resources affinities, as briefly explained Kenny Kerr.
So is it possible under Win7 without having to implement my first idea, and how would you do it?
Direct2D 1.1 is supported on Windows 7 if you install the Platform Update. Unfortunately, that doesn't solve your problem without first creating two more of them: 1) it's still pre-release/beta, and 2) it adds another installation dependency for you to worry about.
I'm currently trying to track down a GDI handle leak. I am currently using GDIView to track it down. The tool divides the GDI objects into categories Pen, ExtPen, Bitmap, Font, Palette, Region, DC, Metafile DC, Enhanced Metafile DC, and Other GDI. These categories are summed in a column called GDI Total. Ontop of that, there's a column called All GDI. It is in this column I am detecting the leak.
As I don't have the source code for the tool, I can't see what's really going on. Did the author of the tool miss a handle type? It looks like it. I do know there is a leak, because some users report that they are shown the infamous dialog A required resource was (end of text). It may take weeks for the dialog to show up, so I'm pretty sure it isn't a DC.
Any ideas on how to track this down would be much appreciated! As I have a limited budget, thousand dollar tools are out of the question. Debugging hooks into GDI would suffice, as I don't mind doing detective work.
I found the problem. Apparently, GDIView thinks that icons fall under the unknown category. The problem was an icon being loaded and attached to an object. The object was not setup to auto delete the icon upon destruction. E-mailing the author of said tool...
Once I had a similar problem and I used Task Manager - asked it to show GDI handles count for each process and stepped over the program code to see where the handles count unexpectedly increases and fails to decrease back. It took some time, but finally using divide-and-conquer I found the error.
I've been having problems and, after spending a week trying out all kinds of solutions and tearing my hair out, I've come here to see whether anybody could help me.
I'm working on a 3D browser plugin for the Mac (I have one that works on Windows). The only fully-hardware accelerated way to do this is to use a CAOpenGLLayer (or something that inherits from that). If a NSWindow is created and you attach the layer to that window's NSView then everything works correctly. But, for some reason, I can only get a specific number of frames (16) to render when passing the layer into the browser.
Cocoa calls my layer's drawInCGLContext for the first 16 frames. Then, for some unknown reason, it stops calling it. 16 seems like a very specific - and programmatic - number of frames and so I wondered whether anybody had any insight into why drawInCGLContext would not be called after 16 frames?
I'm reasonably sure it's not because I pass the layer into the browser - I've created a very minimal example plugin that renders a rotating quad using CAOpenGLLayer and that actually works. But the full plugin is a lot more complicated than that and I just don't know where to look anymore. I just don't know why drawInCGLContext stops being called. I've tried forcing it using CATransaction, it definitely gets sent the setNeedsDisplay message - but drawInCGLContext is never called. OpenGL doesn't report any errors either (I'm currently checking the results of all OpenGL calls). I'm confused! Help?
So, for anybody else who has this problem in future: You're trying to draw using the OpenGL context outside of the drawInCGLContext. There was a bug in the code where nearly all the drawing was happening from the correct place (drawInCGLContext) but one code path led to it rendering outside of there.
No errors are raised nor does glGetError return any problems. It just stops rendering. So if this happens to you - you're almost certainly making the same mistake I made!
Pardon my frustration. I've asked about this in many places and I seriously don't think that there wouldn't be a way in Windows 7 SDK to accomplish this.
All I want, is to capture part of a 'child window' ( setParent() ) created by a parent. I used to do this with bitblt() but the catch is that the child window can be any type of application, and in my case has OpenGL running in a section of it. If I bitblt() that, then the OGL part comes blank, doesn't get written to the BMP.
DWM, particularly dwmRegisterThumbnail() doesn't allow thumbnail generation of child windows. So please give me a direction.
Thanks.
It's been a while since I did any of this, so my explanation might be a bit vague, but from what I remember, the Windows doesn't "see" the OpenGL rendered inside the window.
What Windows does is create the window at the specified size and then "hands it over" to OpenGL for rendering. This means that you can't get at the pixels as rendered from the Windows side of the code.
When we wanted to capture the 3D we had to re-render the screen to an off screen bitmap which was then saved (or printed).
Obviously a whole screen capture (Print Screen) works because it's reading the final pixels.
I suggest that you:
Forget the Thumbnail part of the task (in terms of capture).
Calculate where your window is.
Capture full screen.
Excise the area you are interested in (using data from step 2).
Rescale to the appropriate thumbnail size.
Sorry, its more work, but it should work, which is better than what you have right now.
This may help:
http://code.google.com/p/telekinesis/source/browse/trunk/Mac/Source/glgrab.c?r=140
http://www.codeproject.com/KB/dialog/screencap.aspx
Also Java's Robot class (http://java.sun.com/javase/6/docs/api/java/awt/Robot.html#createScreenCapture%28java.awt.Rectangle%29)
I don't have access to the source code of any child window that may be open including the one with OpenGL