I'm trying to set up a window where Direct X only participates in half of the screen.
My swap chain desc width is half screen, and my viewport width is half screen, but when I clear the render target to blue, the entire screen is blue rather than the half that I have designated for use.
I know that it is old question, but anyway, if someone will come here from search:
MSDN says:
Differences between Direct3D 9 and Direct3D 11/10:
Unlike Direct3D 9, the full extent of the resource view is always
cleared. Viewport and scissor settings are not applied.
Related
I'm coding in c++ on windows 10 - straight win32 API.
I wanted to make a window show up in the top right of the screen.
As I was doing this, I noticed that screen coordinates for a maximized window are left=-8, top=-8, right=1936, bottom=1088.
Also, when I position a window so right=1920 and top=0, there's about an 8 pixel gap on the right. I tried moving the window around to see what screen coordinates I got.
rect.left for a nonmaximized window can go from -7 to 1912.
so things are slid by 7 pixels ? WTF microsoft ??
How am I supposed to come up with the rec.right=1913 value to position my window aligned to right side of screen without that dang gap ?
But rect.right of 1920 leaves a gap. So rect.right of 1912 would leave MORE of a gap...
And I need a solution that'll work back to Vista.
Pre win10, that rect.right should be 1920 like ya expect.
Whaaaaat is going on here? I'm about to start throwing knives around !!
Code wise, this is just what GetWindowRect is reporting...
(excuse my weird debugging function)
::GetWindowRect (_wndo, r);
DBG("ExtRc l=`d r=`d t=`d b=`d w=`d h=`d",
r->left, r->right, r->top, r->bottom, r->right-r->left, r->bottom-r->top);
Well thanks to #ChristopherOicles
This is really his answer. Duplicate this as your own (or tweak it, whatever) and I'll accept your's.
What's going on is microsoft wrecking border widths in windows 10.
GetWindowRect returns the outside window coordinates as screen coordinates.
GetClientRect returns the inside the window coordinates.
Up until Windows 10 (F U Win10 !!),
The difference in width and height between them was the width and height of the borders.
Upon win10, the border width reports 16 pixels, so 8 pixels a side.
However, only 1 of those pixels are visible. 7 of them are transparent.
So your window has a transparent 7 pixels to the left, right, and bottom.
So you need to take those transparent 7 pixels into account if you're going to line up the window on the screen programmatically. The user doesn't want that 7 pixel gap next to the screen border !
DwmGetWindowAttribute with the attribute DWMWA_EXTENDED_FRAME_BOUNDS will get you the width and height of the ACTUALLY SHOWING part of the border in screen coordinates. So similar to GetWindowRect, but the rect does not include the invisible-ness.
You're still going to need GetWindowRect most of the time to set the width and height of your window and those 7 pixels per side of invisible-ness are needed to size the window properly programmatically.
So use the difference between the .left of the rect GetWindowRect returns and .left of what DwmTerribleName returns to get that 7 pixels of offset.
In my opinion, whoever did this at Microsoft should be immediately shot.
This is a hoop I didn't need to jump through.
This breaks compatibility with the past.
This is because of the width of the window border and other factors, which vary depending on OS version, user preference, and DPI settings. See the GetSystemMetrics function.
I have a photoshop file with 8 concentric 'rings' (although some aren't rings and are more irregular), with the largest at the 'back' and decreasing in size up to the 8th one being very small in the centre.
The 'rings' are drawn in such a way as that the smaller ones are 'internal' to its 'outer' or next larger ring. Each 'ring' has transparency on its outside, but also on its inside (where the smaller rings would 'sit').
I need to support all iOS devices (Universal App).
The largest image has a default size of 2048x2048 pixels, but every one of the 8 layers has a common 'centre' point around which they need to rotate, and around which they need to be fixed.
So, basically, all 8 have to be layered, one on top of the other, such that their centres are all perfectly aligned.
BUT the size of the artwork is larger than any iOS device, and the auto-layout has to allow for every device size and orientation, with the largest (rear) layer having an 8 point inset from the screen edges.
For those that can't picture this, here is a crude representation, where the dark background is 'transparent' and represents the smaller of the width or height of the iOS device (depending on orientation):
Note: The placement of where each smaller UIImageView is precise. They all share a common centre (the centre of the screen) but each ring sits 'inside' of the larger ring behind it. i.e. the centre of the green, hot pink and baby pink circles are empty / transparent, and no matter what size screen or orientations, they have to nest together perfectly, as they do in the photoshop art assets.
I've spent hours in auto-layout trying to sort this out, and when I've got it working on one device and both orientations, it's not working on any others.
No code to show because I'm trying to do this in IB so I can preview on all devices.
Is this even possible using IB / Auto-Layout or do I have to switch to manually working out the scales by which to resize their UIImageView based on screen width / height at runtime and the relationship between each 'ring'?
Edit:
And unless I'm doing it wrong, embedding each UIImageView into a transparent UIView in order to use the UIView to fake 'insets', this doesn't work because those numbers are hard coded, such that when it's perfect on a 12.9" iPad Pro, on an iPhone SE each 'inset' UIImageView is much more compressed and doesn't sit 'inside' it's next larger ring, but is like a tiny letter O with lots of surrounding blank space, because those 'insets' don't scale. What is 100pts on an iPad is a tiny amount of space, but 100pts on an iPhone SE is a 1/3 of the screen.
You can draw circles using CAShapeLayer and UIBezierPath. Since you are trying to fit this in a square, I'd define container size to be either the width or height of the parent container depending on what's smaller, this will allow for rotation and different screen sizes. As for the center, you can always find it by getting center coordinates of your square container (container.bounds.size.width / 2). To rotate your layers/sublayers you can use this answer: https://stackoverflow.com/a/3929703/4577610
If I maximize a Delphi form the width and height values are 8 pixles greater that the corresponding GetSystemMetrics SM_CXSCREEN and SM_CYSCREEN?
For Example:
When I right click on my screen and get properties I have a 1680 X 1050 screen resolution. Those are the same values returned from GetSystemMetrics(SM_CXSCREEN) and GetSystemMetrics(SM_CYSCREEN).
When I maximize the form in my Delphi application I get a width of 1688 and a height of 1058. There is an 8 pixel difference. What causes this difference?
When maximized windows were originally implemented, the designers wanted to remove the resizing borders. Rather than removing them, they instead decided to draw those borders beyond the edges of the screen, where they would not be seen. Hence the rather surprising window rectangle of a maximized window.
This implementation decision became a problem with the advent of multi-monitor systems. By that time there were applications that relied on this behaviour and so the Windows team decided to retain the behaviour for the sake of compatibility. This meant that maximized windows leaked onto neighbouring screens. In time the window manager acquired capabilities that meant it could suppress that leakage.
Raymond Chen, as usual, has an article that covers the details: Why does a maximized window have the wrong window rectangle?
I wrote simple program, which catches WM_GETMINMAXINFO. This message allows one to modify position and size of maximized window, before the actual maximization takes place. The default values provided by system were:
Position.x: -8
Position.y: -8
Size.x: 1456 (= 8 + width of screen + 8)
Size.y: 916 (= 8 + height of screen + 8)
The resolution of my screen is 1440x900.
It seems, that Windows positions the window after the maximization in such way, that the client area covers the most the available space and window's chrome is hidden outside the screen area.
I'm using a full screen UIWebView to house/render an HTML5 application under iOS. Very much like Cordova/phonegap although I'm not using those. I try to make my webview size match the underlying display. Unfortunately, on retina displays, the value returned by self.view.bounds relies on the UIScreen scaling factor. So I get 1024x768 instead of 2048x1536. Not a huge problem except I then instantiate the UIWebView using the smaller bounds (after adjusting for the status bar) and some things get a bit jaggy. In particular, I use canvas at a couple of points and also rounded borders appear thick. To be clear, this isn't a case of scaled raster resources.
I'm not getting the full resolution of the screen using that UIWebView. Ideally, I'd like to set the screen scale to 1.0 but that doesn't appear to be supported. Any suggestions on how best to get full advantage of the screen?
The problem is most noticeable on the iPhone 5 simulator. I don't have that hardware to test on. iPad/new iPad I think has the problem but the jaggies aren't as noticeable.
Update: The more I look at this, the more I think it may be restricted to canvas.
Solution: In case anyone else gets here. Based on the answer below, I created all of my canvas elements with width and height multiplied by window.devicePixelRatio and then set their style attribute to have the original (device independent) size.
See https://stackoverflow.com/a/7736803/341994. Basically you need to detect that you've got double resolution and effectively double the resolution of the canvas.
I'm currently working on an OpenGL game, and recently began refactoring it to support iPhone in addition to iPad. In an attempt to give myself as little work as possible, I simply resized the containing EAGLView to 480 x 360 (to preserve the iPad aspect ratio) and shifted the view up so it's y origin lay at -20 (in order to centre the content, and as the edges could be cropped).
I found this resulted in jerky performance on the device (despite the CADisplay link reporting a frame duration that equated to 59-61 fps) and was at least 20% slower when compared side by side with the iPad version.
I then tried resizing the view to the screen size 480 x 320 and the performance returned to normal (though the rendered content no longer has the correct aspect ratio).
Why is it that the 'off screen' rendering causes a performance hit and why does the displaylink still think it is running at 60fps?
Any ideas?
Thanks
This is mostly a wild guess, but what about clipping regions? There was this hardware functionality that made it possible to mix windows and hardware accelerated graphics. Maybe it is not implemented very well on mobile devices.
You could, however, avoid making the UIView offscreen and try to use glViewport() to shift the parts of the view offscreen. While it seems to be the same, it is handled by a different part of the pipeline (the rasterizer), and should be much faster.