I want to copy the contents of an existing Window to my own Window using Xlib. I have tried XCopyArea and it refuses to copy between two Windows. I have also tried XGetImage and XPutImage and it's also failing.
What's the best way to copy the graphics contents of a Window to my own?
Part II:
Based on information below, I was able to get XCopyArea and XGetImage to work. The reason it wasn't working was difference in depth of source and destination Window. I was surprised to learn that different Windows have different depth on my desktop.
But I still have limited success with XCopyArea. If I start copying from the top of certain Windows, like Google Chrome, it doesn't copy the full area, just the title bar. XGetImage works fine in those cases. Any clue on why XCopyArea won't copy beyond the title bar of some Windows?
XCopyArea should be fine.
Note that this will only copy into the foreground of the destination - maybe it is being drawn then erased?
Without code I can speculate:
If it is failing, have you checked that the windows definitely have the same root and depth?
Also make sure you review the X Window coordinate system. Maybe try copying so that the corner of your Copy is in the centre of the Destination to see if you can get anything.
You normally want some way of handling Expose events in the destination window so you can do a refresh.
I'd recommend creating a Pixmap as an intermediate. Both Pixmap and Window are Drawable.
Use XCopyArea to copy into the Pixmap.
Then use XSetWindowBackgroundPixmap to actually render the image. Setting the background means you can then ignore any need for handling Expose events to redraw the image.
Related
I'm currently getting back to some Windows Programming using Petzold's book (5th edition).
I compiled the following example using BitBlt and it doesn't work as it is supposed to.
It should copy the Window's icon of (CxSource, CySource) size and replicate it on the whole window's surface.
What happens, in reality, using Windows 7 is that the bitmap below the window gets sourced and copied into the drawing surface i.e. hdcClient.
I don't understand why it behaves like this knowing that it's clear the DC passed to BitBlt is hdcWindow, which refers to a device context obtained via a GetWindowDC(hwnd) of the current application.
I first thought it was due to the fact the transparency mode is enabled by default, but deactivating it doesn't change anything. BitBlt seems to always take the surface below the application Window!
I don't get it! :)
Anyone knows why it works that way and how to fix it?
Making screenshots with BitBlt() did not exactly get any easier since the addition of the DWM (Desktop Window Manager, aka Aero). Petzold's sample code suffers from a subtle timing issue, it is making the screenshot too soon. It does so while Aero is still busy animating the frame, fading it into view. So you see what is behind the window, possibly already partly faded depending on how quickly the first WM_PAINT message is generated.
You can easily fix it by disabling the effect:
#include <windows.h>
#include <dwmapi.h>
#pragma comment(lib, "dwmapi.lib")
And after the CreateWindow() call:
BOOL disabled = TRUE;
DwmSetWindowAttribute(hwnd, DWMWA_TRANSITIONS_FORCEDISABLED, &disabled, sizeof(disabled));
Another tricky detail is that the first BitBlt matters, the DWM returns a cached copy afterwards that is not correctly invalidated by the animation.
This gets grittier when you need a screenshot of a window that belongs to another process. But that was already an issue before Aero, you had to wait long enough to ensure that the window was fully painted. Notable perhaps is the perf of BitBlt(), it gets bogged-down noticeably by having to do job of composing the final image from the window back-buffers. Lots of questions about that at SO, without happy answers.
It is not supposed to copy the windows icon, it is supposed to copy the windows titlebar part where the icon is located.
There are some issues with this (now 20 year old code):
GetSystemMetrics values cannot be used for window related dimensions anymore since GetSystemMetrics returns the classic sizes, not the Visual Style sizes.
Depending on the Windows version, the DWM might define the window size as something larger than your window (where it draws the window shadow and other effects).
Your example works OK on XP:
(There is a small problem because the titlebar is not square (unlike Windows 98/2000 that this example was designed for) so you see a issue in the top left where it is just white. I also modified the example slightly so it varies the HDC source location)
On a modern version of Windows it seems like the DWM or something is not able to properly emulate a simple window DC and parts of the shadow/border/effects area is part of the DC:
I don't know how to fix this but the example is pretty useless anyway, if you want to draw the window icon you should draw the HICON with DrawIconEx. If you want to draw custom non-client area stuff then you need to find more recent examples, not something that only supports the classic theme.
I'm building an app where I would like to redraw the image on screen around a user's finger touch. System.Windows.Media.Imaging.WriteableBitmap has a method AddDirtyRect(Int32Rect dirtyRect) to indicate to indicate changes my code has made to the back buffer so that the whole image needn't be redrawn. Its Windows Runtime equivalent, the Windows.UI.Xaml.Media.Imaging.WriteableBitmap class, does not.
Can I tell the system which part of the screen to redraw as the result of code changing a Windows.UI.Xaml.Media.Imaging.WriteableBitmap?
No, this API isn't there. You could use a secondary patch bitmap to update only a portion of the rendered output. If you need more control over what gets pushed out to the buffers you'd need to use a SwapChainPanel and DirectX.
Ive been googling this alot but can't find any working solution. Im using Shell Integration Library to cerate custom Window Chrome and I also need drop shadows for this window. Some say setting GlassFrameThickness to -1 do the trick but its not working for me. And Jeremiah Morrill suggested using DwmExtendFrameIntoClientArea. Ive tried that and it works, sort of. The shadows looks ok but when the window is shown it is first shown as a glass-frame and then a second later the real content is superimposed. This causes to much flickering for me. Is there any way to get rid of this flickering or is there any better way using only Shell Integration Library?
I had a similar problem where it wouldn't display any shadow when using a custom chrome. It worked fine when using the glass.
I got a shadow by setting GlassFrameThickness="0,0,0,1". The glass didn't show and I got the shadow.
Be warned, the shadow is a simple RECT to Windows, so if you have a funky chrome with transparencies it may look funny.
Also if you support the maximized state be aware the you'll need to set a margin on your top-level panel element of "8,8,8,8" when in maximized mode. All other modes should be "0,0,0,0".
To alimbada, the WindowStyle defaults to None on custom chrome.
The Shell Integration Library uses DwmExtendFrameIntoClientArea, plus handling of several Window messages to get the effects. If you're using the full window rect (i.e. no rounded corners) then setting it to (0,0,0,1) as suggested will give you the drop shadows as you want. If you want to simulate the rounded corners of Aero, then setting it to (8,8,8,8) will extend the glass frame enough that the corners also stay rounded, and then you're responsible for not drawing over the corners of the rectangle. The shape of the drop shadow doesn't change regardless of the glass frame thickness.
The flashing you're seeing when setting the thickness to -1 still exists even when not fully extending the glass frame. What's happening is the window is getting shown while the content is still compositing. What you can do is simplify the default UI so it displays quicker (or you can stage it, bringing in a simnple background first and then replacing it with something usable), or you can create and show the window off-screen, and then move it to the desired start location once the content has been rendered. The easy way to detect when it's probably ready is to invoke a DispatchTimer with Priority=Loaded. That should only get invoked once the basic first layout has been completed.
Using gdk_screen_get_monitor_geometry, I can get the total area in pixels and the relative position of each monitor, even when there are two or more used as a single screen.
However, I want to get the usable area (that is, excluding panels) of each monitor. The only thing I have found is _NET_WORKAREA, but that is one giant area stretching across all monitors. Depending on the resolution and arrangement, there may be panels inside this area.
How can I get the actual usable area of each monitor? Ideally, using only Gtk/Gdk, nothing X11-specific.
The following approach is a bit convoluted, but it is what I'd use. It should be robust even when there is complex interaction between the window manager and GTK+ when a window is mapped -- for example, when some of the panels are automatically hidden.
The basic idea is to create a transparent decorationless maximized window for each screen, obtain its geometry (size and position) when it gets mapped (for example, using a map-event callback), and immediately destroy them. That gets you the usable area within each screen. You can then use your existing gdk_screen_get_monitor_geometry() approach to determine how the usable area is split between monitors, if any.
In detail:
Use gdk_display_get_default() to get the default display, then gdk_display_get_n_screens() to find out how many screens it has.
Create a new window for each screen using gtk_window_new(), moving the windows to their respective screens using gtk_window_set_screen(). Undecorate the windows using gtk_window_set_decorated(,FALSE), maximuze them using gtk_window_maximize(,TRUE), and make them transparent using gtk_window_set_opacity(,0.0). Connect the map-event signal to a callback handler (using g_signal_connect()). Show the window using gtk_widget_show().
The signal handler needs to call gtk_window_get_position() and/or gtk_window_get_size() to get the position and/or size of the newly-mapped window, and then destroy the window using gtk_widget_destroy().
Note that in practice, you only need one window. I would personally use a simple loop. I suspect that due to window manager oddities/bugs, it is much more robust to create a new window for each screen, rather than just move the same window between screens. It turns out it is easier, too, as you can use a single simple callback function to obtain the usable area for each screen.
Like I said, this is quite convoluted. On the other hand, a standard application should not care about the screen sizes; it should simply do what the user or window manager asks. Because of that, I would not be surprised if there are no better facilities to find out this information. Screen size may change at any point, for example if the user rotates their display, or changes the display resolution.
in the end I ended up using xlib directly, various "tricks" like the one suggested above ended up eventually failing in the long run often with odd corner cases and never followed the KISS principle.
The solution I used is in the X-Tile code base.
I have a full length movie file on the server. I want to create a wall of media clips from that one file. I can create the clip functionality by setting the position for the start of the clip and listening for a marker telling me when to stop playing. However, I would like to have the Media Element stop download the rest of the file at the point I stop the clip from playing for obvious performance and design implications.
Unfortunately, you cannot control what the MediaElement downloads directly, other than setting the Source to null (which I am assuming is not what you want).
You might be able to download part of the file using HTTPWebRequest, making a copy of the returned Stream and setting it to the MediaElement (via SetSource), but that would only work if the clip is close to the beginning of the file.
There might also be server-side solutions:
- Save each clip as a separate file (work up front, but will minimize unneeded downloads). Tools like Expression Encoder may be able to help you do this quickly and in batch.
- Create a server entry point that accepts a file range, and only sends data up to a certain point. This is a non-trivial amount of work, but it makes the client completely unaware that not the entire file is sent.
Hope this helps, and sorry I don't have a better answer.
Ed