The same project compiled on the identical versions of Windows 10 and Visual Studio 2015 but on different hardware (Asus laptop and Surface Pro 4) produces different results: some elements (like MapPolyline and borders of MapPolygon) are not drawn along with the whole streets outlines and such (see the attached screenshots)
Expected behavior
Problematic behavior
Does anybody experience similar behavior and/or know how to fix that?
I think this is the same bug as reported here http://answers.microsoft.com/en-us/windows/forum/apps_windows_10-win_maps/windows-10-maps-app-sometimes-does-not-show-the/7183916a-9567-4d49-ab92-297eec8737ab?auth=1 Microsoft is working on a fix...
Related
I'm currently experiencing a weird issue that looks like Z-Fighting with Direct3D 9. I suspect that my problem is actually a Z buffer precision issue.
I noticed that absolutely no depth artifacts appear in Debug builds (I'm using Visual Studio 2012). The bug only occurs in Release builds.
The depth buffer format I'm currently using is 24-bits padded with 8 (D3DFMT_D24X8). When I use only 16-bits, the exact artifacts appear in both Debug AND Release builds. So what does that mean? Is DirectX rejecting 24-bits depth buffers? And if that's the case, why would you even do this?
Aside from all that, I tried setting 32-bits, but it just crashes and returns a null-pointer for the D3D device.
Many thanks in advance.
Here's a screenshot of my problem :
Ok, so I eventually found a work-around. I divided my scene into regions of depth, and I'm rendering all of them one by one after clearing the Z-buffer between each passes.
I currently have two passes (0.1m to 5m, and 5m to 10km). This seems to work pretty well for now.
My setup:
Microsoft Surface Pro (version 1), Windows 8.1, Netbeans 8.0, Emacs 24
I noticed that with any given font, in this case Consolas 14, the Netbeans text size is not only smaller, but super crisp on the display. On Emacs, Consolas 14 is huge and kinda blurry. On other programs the text is also not as crisp as on Netbeans. I'm aware there is sub-pixel stuff going on with cleartext, dithering, etc.
So what is Netbeans doing, specifically to look this awesome? Can I get Emacs to look the same? Why is the text different size given the same pt size of 14? How can I get the text to look like this in my programs (assuming on JVM)?
On a regular LCD monitor driven by Surface Pro, the Netbeans text looks a bit less crisp, but the size difference remains, so I attribute this to it being a somewhat lower quality monitor.
I can't necessarily answer your question of "what is Netbeans doing" per se, but I can offer one method for improving the appearance of emacs.
After a bit of research (mostly trial and error, honestly), I found the problem to be related to Windows and its "display scaling." There are many discussions about display scaling on the SP[23] in general, including when connecting to an external display that is not high DPI, Windows is not offering independent scaling factors.
The answer to your question is (I think) loosely related to that. I was adjusting Windows compatibility parameters (right-click on the emacs icon and select Properties then go to the Compatibility tab) for another application when I noticed some options that adjusted color modes (no effect) and DPI scaling (big effect). After some comparisons, I found that checking Disable display scaling on high DPI settings provided a considerably better experience on my screen.
Granted, it isn't "as good" as the same text displayed in, say, Microsoft Word, as really-close-up visual inspection may reveal. Additionally, whenever I put emacs on my non-DPI external monitor, the menus and such as huge, but that's something else to deal with.
In the image below, for comparison is some text in Microsoft Word (top 1) followed by three anti-aliasing options each without (middle 3) and with (bottom 3) the display scaling disabled. The Windows Properties window, Compatibility tab are overlaid for quick reference to what is set. (One interesting side-effect is that the text is roughly 4% smaller now in addition to being much clearer.) Though this example is using the Ubuntu Mono font, it appeared to work equally well with Consolas.
(Windows 8.1, SP3, emacs-24.4.1 from vgoulet.)
This is simply an update on the answer by r2evans. In my version of Windows the Disable display scaling on high DPI settings option no longer exists. Instead, there is an option to Override high DPI scaling behaviour. Setting this to Scaling performed by: System clears up the issue for me.
I've seen that some Google's or other open source projects have resource directories like /drawable-v14 or /drawable-hdpi-v11.
Now, I understand what this means: all devices with SDK larger or equal than v11/v14 should use these images.
But what is the purpose of this? Why and when should I use them? Why devices of HDPI resolution and SDK v11 should ever use images different than HDPI devices and SDK 10?
I just cannot see when I will ever use one image for SDK 10 and another for SDK 17, for example. Makes no sense to me.
As a side note, the usage of resources /values-v{11/14/17} is logical and has the practical benefit.
This can be use in order to style your icons to the current UI guidelines on the given Android version.
Android has had a lot of evolution on its GUI style from its beginning. In Cupcake, icons had to show a 3D effect with a shadow. With ICS, there is more flat icons. And it will keep on changing with android 5 and more... (Let's watch the Google i/o 2014 to know more about it! ... by the way: its today!)
So basically you can stick to the GUI guidelines even from different Android versions. It's probably not the only use case but it is one of them.
I have a repeating XAML animation of multiple scaling arrows which update several times per second which has worked fine on Silverlight, Win8, WinPhone7, and WinPhone8. But now, with the Windows 8.1 Preview I'm getting the following unexpected behavior:
Initial display of the animated arrows is correct through one cycle of all scaled sizes.
On the second and subsequent repetitions of the animation, the arrows are scaled to the correct size, but are all apparently scaled up versions of a low rez, cached bitmap of the arrow. This looks horrible.
If I switch apps and return to my app, the initial display is correct and then reverts to the bad low-rez version (in other words behaviors 1 and 2 repeat).
I would assume this is due to some change in UIElement caching behavior in Win8.1 Preview, but can't find any documentation of a change in this area.
UiElement.CacheMode would seem a likely candidate to effect a fix, but I'd like to know if this behavior is by design or will require code changes for the final release.
Answering my own question: A work around to the bug/feature in Windows 8.1 Preview XAML is adding the following to the TransformGroup associated with the problematic UIElement:
rotateGroup.CacheMode = null;
I have absolutely no idea why this change was necessary. One further description of the problem before the above hack was added:
If the arrow resizing changes incrementally by a small amount, then the bug appears. If the scale factor changes in larger jumps, then the bug goes away and the arrows display correctly.
I'm making an app and I'm nearing completion, now I'm trying to optimize it for different screen sizes and pixel densities. One of the devices (using an emulator) is really frustrating me. I can't seem to find a qualifier that edits the Notion Ink Adam (1024x800 or something, 10.1 inches). According to this: http://developer.android.com/guide/practices/screens_support.html , Notion Ink Adam at 10.1 inches should be considered "xlarge" in a qualifier. However, when I use this in my qualifier like "layout-xlarge" the Notion Ink Adam emulator doesn't follow it.
I also tried using "layout-xlarge-hdpi" because I have another folder that's "layout-hdpi" that the Notion Ink Adam follows, but I'm using THAT qualifier for other devices. Also I've tried "layout-hdpi-long" but it also edits my other "long" hdpi devices. Notion Ink Adam is a tablet, and I'm just trying to seperate: 1) tablets like the Notion Ink Adam, 2)MDPI screens, the smaller screens, and 3) Long hdpi screens like the Nexus One and Motorola Droid.
My main problem is trying to find a qualifier that seperates 1 and 3, the tablet always follows my qualifier for the long hdpi screens.
Support for xlarge devices was introduced only in Android 2.3 (Gingerbread) and later. If your Adam is still running Froyo, it will report itself as "large" and will not find xlarge resources.
I developed an app, "ScreenInfo", which will cause an Android device to report its screen size and density classification. You can find it in the Market, or grab the source.
To help you sort out the various categories:
small-screened phones (like the original G1): normal-mdpi
most high-end smartphones w/3.7-4.5 inch screens: normal-hdpi
small-screened tablets (7-inch): large-mdpi, or in the case of the Galaxy Tab 7, large-hdpi
large-screened tablets (10-inch): xlarge-mdpi
As far as I'm aware, you're already doing everything correctly - using -xlarge for tablets, -hdpi, -mdpi, and so on for the appropriate screen densities, and so on. If the Adam's emulator (or the actual device) don't pull from the -xlarge layout already, it's probably in your best interest to simply ignore it. It's not a particularly popular tablet now that the Android 3.x devices are out (probably wasn't even before that, but I don't know), and if they're ignoring standards, all the more reason to ignore them in favor of what works for the majority of devices.
In terms of common qualifiers, I'm not sure what you mean, but if you go by the information in the documentation you linked, that's what's "common."
Adam reports itself as a large device. So, xlarge resources wont work on Adam.