I am drawing to a regular HwndRengerTarget but other windows, which have nothing to do with Direct2D, overlap it.
The problem is that these windows get painted over when I draw to the HwndRengerTarget.
I would like to tell Direct2D not to touch a specific region of the HwndRengerTarget (i.e. don't touch the pixels that are already on the screen), so that these windows remain correctly visible.
Is that possible?
If I draw normally then call RedrawWindow on the windows, it flickers a lot.
Thanks.
If you want to manually restrict your rendering to a certain region you can use layers (ID2D1Layer objects).
More info here Layers Overview
If the visible region is rectangular it may be simpler to use axis aligned clips via methods PushAxisAlignedClip and PopAxisAlignedClip.
ID2D1RenderTarget::PushAxisAlignedClip
Another method of restricting drawing to a certain shape is to render it to a bitmap and then use this bitmap via a bitmap brush in the FillGeomtry method.
ID2D1RenderTarget::FillGeometry
Why not arrange the windows (HWNDs) so that the Direct2D one is at the bottom of the z-index? It should be the first child of its parent. Then clipping will be automatic. You may need the WS_CLIPSIBLINGS window style.
I had the same problem.
Fixed by calling CreateWindowEx LAST for the D2D child HWND.
So AFTER all the other child windows are created.
Related
I am new to win32 programming and have a very naive question.
Say there is my application window of size 1920x1280 and I create a child window over it of size 1920x2560 (double of vertical screen size). Now I load an image onto this child window which has the same size as that of child window i.e 1920x2560.
Now my question is If I use ScrollWindow for vertical scroll, will I necessarily need to repaint the dirty rect (the bottom part), since the image would be already loaded? Is it not possible to avoid that and just move the screen buffers ? Or is there any other way possible to avoid redrawing, may be using bitmaps or something?
An application draws in a window when scrolling, changing, or
selecting a portion of the displayed
data
but you could only draw the differences in the Update Region.
It's also noted that disabling the default handling for the WM_ERASEBKGND message makes smooth.
The disadvantage of your idea is always drawing outside of client area and how to just move the screen buffers to avoid redrawing?
While there are lots of variations of the question, there doesn't seem to be a specific answer to a simple case of wanting to use built-in common controls on a transparent window using Win32. I don't want the controls to be transparent, I just want the border around it to be transparent. I can't believe MS didn't update the .dll's to handle transparency when they added it, but I guess they forgot? Is there a specific method that works. A button can get close with WS_EX_TRANSPARENT, but flaky where it works most of the time but at times part of the border shows up. Edit controls, change depending on when get focus or not.
So the question is simply:
Is there a way to make common controls on transparent window so there is no white border around them?
If not, is there a good replacement library that does it via owner draw?
If some, which ones and what is the method?
Seems silly to reinvent the wheel just because of the area around the control.
TIA!!
If I am not mistaken, you can take the following steps to achieve this effect.
1.Create a GDI+ Bitmap object with the PixelFormat32bppPARGB pixel format.
2.Create a Graphics object to draw in this Bitmap object.
3.Do all your drawing into this object using GDI+.
4.Destroy the Graphics object created in step 2.
5.Call the GetHBITMAP method on the Bitmap object to get a Windows HBITMAP.
6.Destroy the Bitmap object.
7.Create a memory DC using CreateCompatibleDC and select the HBITMAP from step 5 into it.
8.Call UpdateLayeredWindow using the memory DC as a source.
9.Select previous bitmap and delete the memory DC.
10.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 button.
A similar discussion: Transparent window containing opaque text and buttons
We need to overlay a target window with a custom shape and tracks the position of the target window such that the overlay drawing always appears above it. Also, the overlay drawing should appear in screenshots taken using BitBlt or PrintClient by screen-capturing tools like Camtasia, Debut, etc. Also, moving the target window around should not leave traces of the drawing at earlier location. The target window is not made using our code.
So far we've tried several ways but each method has its problems:
1) Layered Window:
Using a layered window as the child/owned window of the target window is the easiest thing and it works. But the problem is on Windows 7 and XP, layered windows do not appear in a BitBlt done without the CAPTUREBLT flag and the screen-capturing tools may call BitBlt without the flag, thereby skipping our window from the capture.
2) Region Window:
The crude approach to support all Windows versions then is to use a region window using SetWindowRgn and make the target window its owner. However, region windows are generally very slow in rendering complex shapes and also impact the performance of other windows, sometimes to the point of freezing the application. Region window also leaves traces on dragging the application window.
3) Subclassing and Drawing on HDC:
Another approach is to sub-class the target window and draw the shape on its HDC on the OnPaint() event inside the window procedure hook. The shape can be drawn on the desktop window instead too. The problem is that applications may draw without a paint event, like when some text is selected using the cursor, and such drawing may erase a part of the custom drawing. Tracking all possible paint events is not a good way to do this.
4) Drawing continuously in a timer:
The last resort is to draw the custom shape on the target window in a timer continuously so the drawing is always above the target, even on text selection. But this may show a bit of flicker when the text is selected. Not to mention, it is very performance heavy to draw constantly.
Question
What is the best way to achieve an overlay drawing which works on all Windows versions (since XP) at the same time appearing in screen-captures. We've exhausted all approaches. Is there some method I'm missing? Can the above mentioned ways be used with some improvement? Is DirectX an option? I'm looking for methods with fast rendering capacity to achieve this. Appreciate any help!
I think the best solution to draw an overlay window, is to use a double-buffered technique GDI, just like in this example:
Overlay Drawing in CScrollView
I have myself the same task, and the only solution was that one. Hope it help you.
I am implementing a border control in win32, and I have implemented various styles for that border. I am using simple MoveTo() and LineTo() commands for drawing the border.
My problem is, when i select some new style for my border, it starts painting over the currently drawn border. I understand i need to refresh/repaint my window inorder to have a fresh canvas. I am using InvalidateRect() for now to achieve this purpose. But I am concerned, If i have other windows associated with my border control window (as child windows), how will this effect the child windows?i will need to repaint everything on this window, correct?
Secondly, Is there anyway I can draw lines inside a GDI Region (HRGN)? So far, all i have come across is how to fill up that HRGN with some fill color. Is there anyway i can retrieve HDC associated with that particular HRGN object??
This is not a concern, anything you draw is automatically clipped by the child window rectangles. No extra code is required. The underlying window style flag is WS_CLIPCHILDREN.
You cannot draw lines in a region nor are they associated with a device context. Other than by drawing the region and then drawing the lines in your paint message handler. You are probably interested in paths. The MSDN docs start here.
Reading https://learn.microsoft.com/en-us/windows/win32/direct2d/comparing-direct2d-and-gdi :
Presentation Model
When Windows was
first designed, there was insufficient
memory to allow every window to be
stored in its own bitmap. As a result,
GDI always rendered logically directly
to the screen, with various clipping
regions applied to ensure that it did
not render outside of its window. In
contract, Direct2D follows a model
where the application renders to a
back-buffer and the result is
atomically “flipped” when the
application is done drawing. This
allows Direct2D to handle animation
scenarios much more fluidly that GDI
can.
The author says Direct2D uses back-buffer and by 'flipped' he meant swap-chain I guess. I created a simple demo that draw a rectangle at random location on mouse click. But previous rectangles are not cleared so it seems that it is drawn directly to the screen and does not use any back-buffer.
When you initialize the RenderTarget for your Direct2D operations you can specify in the second parameter the D2D1_PRESENT_OPTIONS option.
I think what confuses you is the D2D1_PRESENT_OPTIONS_RETAIN_CONTENTS and the fact that the buffer isn't swapped but copied.
That doesn't disprove the existence of back-buffers, it only means the back-buffer isn't cleared between redraws. Right observation, wrong conclusion!
If you increase the number of back-buffers in the chain, you'll start noticing flickering rectangles as you keep clicking, so you should always clear your back-buffer between redraws.
Direct2D indeed uses back-buffer.
Perhaps you forgot to clear your render target, which is the back-buffer, right after calling begindraw and so previous draws stayed there?