I want to get display info via Xlib, specifically:
iterate displays
get the screen rectangle for each display (relative to the virtual screen - does X11 have the concept of a virtual screen on which physical screens are mapped, similar to Windows and OSX?)
get the client area rectangle (so screen minus taskbar etc.) for each display
Thanks.
Half answer: using XineramaQueryScreens() I was able to enumerate displays and get their coordinates in the virtual screen and their sizes. Now how do I get the desktop size, i.e. the size that the windows maximize to?
You need to read _NET_DESKTOP_GEOMETRY (also maybe _NET_DESKTOP_VIEWPORT and _NET_WORKAREA )
Related
We have an application which has a window with a horizontal toolbar at the top. The windows-level handle we pass to Vulkan to create the surface ends up including the area behind the toolbar i.e. Vulkan is completely unaware of the toolbar and the surface includes the space "behind" it.
My question is, can a surface represent only a portion of this window? We obviously need not process data for the pixels that lie behind the toolbar, and so want to avoid creating a frame buffer, depth buffer etc. bigger than necessary.
I fully understand that I can accomplish this visually using a viewport which e.g. has an origin offset and height compensation, however to my understanding the frame buffer actually still contains information for pixels the full size of the surface (e.g. 800x600 for an 800x600 client-area window) even if I am only rendering to a portion of that window. The frame buffer then gets "mapped" and therefore squished to the viewport area.
All of this has sort of left me wondering what the purpose of a viewport is. If it simply defines a mapping from your image buffer to an area in the surface, is that not highly inefficient if your framebuffer contains considerably more pixels than the area it is being mapped to? Would it not make sense to rather section of portions in your application using e.g. different windows HWNDs FIRST, and then create different surfaces from then onwards?
How can I avoid rendering to an area bigger than necessary?
The way this gets handled for pretty much every application is that the client area of a window (ie: the stuff that isn't toolbars and the like) is a child window of the main frame window. When the frame is resized, you resize the client window to match the new client area (taking into account the new sizes of the toolbars/etc).
It is this client window which should have a Vulkan surface created for it.
I am trying to resize a window that covers entire screen.
I tried out following
win.Left = SystemParameters.VirtualScreenLeft;
win.Top = SystemParameters.VirtualScreenTop;
win.Width = SystemParameters.VirtualScreenWidth;
win.Height = SystemParameters.VirtualScreenHeight;
This works perfectly on a monitor of 1080p (Full HD monitor). It also works when I have two monitors attached and one of which is full HD where as the other is an HD monitor. I understand that in such case some of the part of the window will never become visible as it will go out of the bounds of total screen asset.
The problem starts with 4k monitor. On a 4k monitor, it consumes a smaller rectangle on screen and does not span to cover the entire screen. I understand that this is due to scaling (wpf automatically scales window) but not able to find a way to overcome this issue.
The issue is just with the 4k monitor. I assume that it has something to do with DPI as the 4k monitor has higher DPI.
My question is, how to make the application use entire screen asset irrespective of monitor resolution and DPI.
(Please note that setting window maximized will not work as it will not span it over multiple monitors.)
It turned out that the issue was not with resizing of window at all. Window was properly resizing after specifying the co-ordinates. However, there is one thing which might help those who want to do similar thing. Always make sure that you compare the values retrieved form API with the other values from API and WPF with WPF as WPF yields scaled values.
Using the designer. My form has a layout BoxLayoutY. I just drop the ImageViewer in it. I have a pic added through "Add Picture", which is 1080 x 1400. I add it to the ImageViewer.
The "Simulate Device" command gives, in iPhone3:
And in Nexus (the pic below is static: can't be scrolled up or down):
Help?
I have installed the app locally on my Android and I get the same half cut pic as in the screenshot of the Nexus simulator.
The overal goal is to have a single form, scrollable vertically, showing pics (adjusted at the width of the screen) and text.
EDIT:
Could be a problem with the resolution of the pic. I decrease the res to 350 x 467 and it displays fine. So it will pixelize or won't scale to fit the width of the screen on larger devices?
The image viewer doesn't have a preferred size since it doesn't have an image in it. Its designed for usage full screen or within a predetermined layout. If you place it in the center of a border layout it will take up available space and work as expected.
Since it scales the image and allows manipulation of that images size, its size is flexible. If you want a component that takes up the exact image size you should use a Label.
Ok got it!
What I was doing wrong was that I had:
MainForm (in a BoxY layout)
-> a container nested in it (in Borderlayout)
---> an ImageViewer nested at the center of it.
This produced the effect above (half cut pic).
Instead, what achieved a properly sized pic was:
MainForm (in a BorderLayout).
-> The ImageViewer nested at the center of it. That's it, no container.
I would happily provide a screenshot of this, however the problem is the captured image, is much larger than my actual desktop.
I am completely frustrated with this as I have tried using BitBlt with the desktop hdc AND the new "Graphics" commands.
My actual desktop resolution is 1920x1080 - 1080p .
BitBlt and "Graphics" both return that my resolution is 1536x864 # 96 DPI.
A form (WinForm), Maximized, borderless, and irrelevant of scaling mode the form is set to, also shows 1536x864 # 96 DPI.
Now the image that is captured, is like it is being done from 1920x1080, but clipping the region 1536x864 as the screenshot.
If I do PrintScreen directly using Prtscn button, I get the entire image, but still it is about 1.5-2x larger than what I actually see.
What I am looking for -- is a resolution for how I can take a picture of what is on my screen in the scale/dpi/whatever is going on here that it visually looks like. I have written a screen capture program, and using a few different examples for the RubberBand form (overlay form to select a region of the screen by drawing a box), and as you can imagine, this scaling crap is causing those box captures to be offset, and the contents are zoomed.
This is very annoying -- even to explain, however I am positive that most of you are familiar with the terms I use, and also know what to expect from taking a screenshot, so my explanation above should be pretty clear as to what my problem is.
Example/Consideration
Imagine, taking a picture of a window that is 300x300, and getting the top left 150x150 of that zoomed to 300x300 completely skipping the remainder of the window. Resulting image is still 300x300, but it's not what you selected.
Now imagine, you grab a picture of your screen by the only dimensions you can get programmatically, and then put the image into a picturebox. Even though both your screen and the picturebox claim to be the same dimensions and dpi, the image in the picturebox requires scrolling even if the picturebox is maximized to fullscreen on a borderless with no borders / etc. -- again, the picture is zoomed, but how is it still reporting that it's the same size as the form XD (comparing Graphics or BitBlt dimensions with the actual form. also tried comparing picturebox contents, and still same effect)
This, is EXACTLY what the effect is that is happening. When I try to capture a region or segment of the screen. I am not sure why windows api/crl is lying about this seemingly trivial stuff, however there must be a way to accurately obtain screenshots/capture regions without this faux zoom effect -- across all resolutions.
Thank you Hans Passant for pointing me in the right direction.
To add "true" dpi scaling support to a winforms application, you can make it so by adding the following block to your manifest :
Project > Add New Item > Visual C# Items > Application Manifest File
One the file has been added, open it up and look for a line like
</asmv1:assembly>
Whatever the "asmv" number is, (in the example above it is 1), use that to format the code:
<asmv1:application>
<asmv1:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv1:windowsSettings>
</asmv1:application>
Paste the above code (changing the asmv1 to whatever version the manifest is), just above the final closing line for the ""
Also, make sure your forms are set to AutoScale to dpi (and all sub-elements).
Windows Phone 7 have a lot of cool "helpers", that allow easly to manage user touch, pinch to zoom and so one. But i actually want to get more info (for example size of the finger)
Is there a way to get raw data from touch screen, like regions of contact user fingers, there shape, size?
The closest you will get is the Touch class and it's FrameReported static event, but it will not give you the shape of the touch point.
You can use the TouchFrameEventArgs.GetTouchPoints method to get the collection of TouchPoint instances, which includes the position and size of each touch point.