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.
Related
If I load a checkerboard texture into Godot:
And stand far enough back from it, I get strange artifacts called Moiré patterns:
This is a well-known problem in computer graphics which appears whenever you sample a texture that has a higher resolution than the area of the screen it is being rendered onto. (See this article for another illustration and full explanation.)
The usage of mipmaps is a technique to eliminate this problem by making lower-resolution versions of the texture that are then used when the camera is sufficiently far away from the object. So, I went to find out how to enable this in Godot only to find out that it was already enabled by default:
Why then am I still getting aliasing? What can I do to eliminate it?
By default, Godot selects a higher resolution mipmap than what is needed to completely eliminate aliasing. At the cost of making your materials blurrier, the aliasing can be almost entirely removed by increasing the "Texture Mipmap Bias" by one. What this does is tell Godot's rendering engine to pick the mipmap that is half the resolution of the one it would normally pick. The setting can be found as follows:
Go to Project > Project Settings....
Enable "Advanced Settings" to the right of the search bar.
Navigate to Rendering > Textures on the left.
The setting can then be found in Default Filters > Texture Mipmap Bias on the right.
The result:
I'm running SolidWorks 2019-2020 on a Windows 10 laptop with a screen resolution of 3840 x 2160. I can create parts and sketches just fine, but the numbers on smart dimensions are so small that I can't even see them. I haven't found a way to change a default setting to resolve this issue - I've only resolved it on single documents. Thoughts?
There is no SolidWorks system option for this but there is a document option property you can use:
If you set it ON the text of the dimensions will show at the same size, even when zooming.
But since you are using a larger screen resolution, this will be too small.
If you set it OFF, you can set the scale of the dimension text to be scaled larger on a per document basis. If you want to use this setting everywhere, the only option is to change this in your template document.
It might be a good idea to file an enhancement request to SolidWorks for handling larger screen resolutions. It feels like this will be needed more and more in the future. If you put the link here, I will vote for it.
Now that the new Macbook Pro is coming out with a Retina Display, there are a lot of resources out there on how to make Mac apps and now even websites "Retina Display Friendly". Even Google is updating Chrome for Retina Display...
Why is this necessary at all? From what I understand, Retina Display is just a higher resolution screen. Right?
I thought when you develop gui's for desktop software and develop websites, you are developing something that is supposed to work and scale properly with virtually any resolution... When you resize an app's window, or display it on a higher or lower resolution display, it is supposed to scale and display properly.
So why are these people coming out with guides on how to make something look good on a Retina Display? Shouldn't it already look fine by default? Is there something about Retina Display that I'm not understanding?
And for the record, I'm not talking about iPhone 4 Retina Display. Most iOS dev's make their apps with fixed position elements since they know the screen's won't change size/shape. So I understand the importance of developing an app to look good on the iPhone 4/s vs 3g/s.
With the Retina display apps don't actually scale like they're being resized, all the controls are resized to be twice as big. If an app would be scaled normally, not by scaling all the controls, etc. you wouldn't see anything, because everything would be too small. It's the same difference between a Retina and a lower-resolution display as on the iPhone 3GS / iPhone 4.
An example:
These images are actually the same size, just the pixel densities differ.
And here's how it looks not properly scaled (using some app to disable proper scaling):
http://cloudmancer.com/images/trueretina.jpg
I thought when you develop gui's for desktop software and develop websites, you are developing something that is supposed to work and scale properly with virtually any resolution... When you resize an app's window, or display it on a higher or lower resolution display, it is supposed to scale and display properly (StackOverflow, for example, uses a 960px-wide container).
From a web developer standpoint, you are often asked to develop fixed-width websites (ranging from normally 940 to 1000 pixels wide), and they don't get to scale at all. There are a lot of websites like this and many apps just aren't designed to increase in size.
Also, apps that do grow in size usually expect that a bigger resolution also means a bigger screen, so they simply stretch the main application panels and are done with it.
Now, consider static elements, like a 150x50 button that says 'Click me'. This button is not intended to become bigger and is perfectly acceptable on a regular 1440x900 display. Now the retina screen comes in with its 2580x1800 resolution. The app sees the resolution change but it thinks "Hey, that user must have a huge screen" so it keeps the button the same size.
The problem that now occurs is that the button, because both resolutions apply to the same 13" screen, is now appearing to be a fraction of the size of the original button. Depending on your user vision, he might not be able to read the text on it, and might have a hard time clicking it, depending on the mouse settings.
To fix that problem, Apple and Microsoft used two different solutions:
Microsoft decided to tell the app the display had a 2580x1800 resolutions, but that the user wanted to have everything scaled to 200 dpi. This means that, if an app does not follow the guidelines, it will look smaller. Many apps simply ignore the DPI settings (though this might change with Windows 8);
Apple decided to report to apps that the resolution of the monitor was 1440x900, but that it could display higher-resolution elements if asked to; This means that apps existing before the new retina settings will appear to be the same size as before for the end-user (with added benefits like crisper text if they use the default Apple APIs), but that they can decide to provide high-DPI images that will look much better on the display.
Both solutions requires apps to be aware that the display is high-DPI ('retina'), but the way Apple handled it means the static websites and apps mentioned earlier will keep looking just fine, except they wont have super-crisp, high-resolution images to use. And, to opt-in to the retina features, they have to provide 200x200 images for a 100x100 canvas, for example, and Apple will take care of the rest.
I'm running in a bit of OC situation here. I'm developing an application using LWUIT 1.5. So I'm almost done with the application, I've already added transitions in fact. But I noticed that the application is lagging on the phone(My current test phone is a Nokia C3-00). The transitions are starting halfway.
Do you guys have any advise on how do i optimize my application? I know I could use the Next Form properties of the Form, but I wouldn't want to always show a "splash screen" every time the user will go to another screen.
Nokia's are often very slow with translucent images, any image that contains a translucent image would be pretty slow which includes image borders. Another culprit is overly narrowly cut image borders, there is a workaround for this in Codename One though.
Remove the theme and create a blank or theme that only uses colors. See if speed improves.
Assuming it does then slowly remove suspect elements from your theme. If it doesn't then see if you load large images etc.
I'm currently designing my first ever GUI for Windows. I'm using MFC and Visual Studio 2008. The monitor I have been designing my program on has 1680x1050 native resolution. If I compile and send my program to one of my coworkers to run on their computer (generally a laptop running at 1024x768), my program will not fit on their screen.
I have been trying to read up on how to design an MFC application so that it will run on all resolutions, but I keep finding misleading information. Everywhere I look it seems that DLUs are supposed to resize your application for you, and that the only time you should run into problems is when you have an actual bitmap whose resolution you need to worry about. But if this is the case, why will my program no longer fit on my screen when I set my monitor to a lower resolution? Instead of my program "shrinking" to take up the same amount of screen real estate that it uses at 1680x1050, it gets huge and grainy.
The "obvious" solution here is to set my resolution to 1024x768 and redesign my program to fit on the screen. Except that I've already squished everything on my dialogs as much as possible to try and get my program to fit on screen running at 1024x768. My dialog fonts are set to Microsoft Sans Serif 8 but still appear huge (much larger than 8 points) when running at 1024x768.
I know there HAS to be a way to make my program keep the same scaling... right? Or is this the wrong way to approach the problem? What is the correct/standard way to go about designing an MFC program so that it can run on many resolutions, say 800x600 and up?
I assume your application GUI is dialog based (the main window is a dialog)?
In that case you have a problem, because, as you discovered, MFC has no support for resizing a dialog correctly. Your options are:
Redesign your GUI to use a SDI or MDI GUI.
Use a dialog resize extension. There are many available, for some very good suggestions see this question. Another options are this one and this one.
Don't use MFC. wxWidgets has much better support for dialog resizing.
MFC is only a thin wrapper over the Windows API. They both make an assumption which is hardly ever true: if you have a higher resolution screen, you'll adjust the DPI or font size in Windows to get larger characters. Most of the time, a larger screen size means a larger physical monitor, or a laptop where you want to squeeze as much information into a small screen as possible; people value more information over greater detail. Thus the assumption fails.
If you can't squeeze your entire UI into the smallest size screen you need to support, you'll have to find another way to make it smaller. Without knowing anything about your UI, I might suggest using tabs to group the controls into pages.
I've had good luck making my windows resizable, so that people with larger screens can see more information at once. You need to do this the hard way, responding to the WM_SIZE message to the window and deciding which controls should be made larger and which ones should just move.
There is no automatic way to resize the content of your dialogs when resolution changes. So, you need to set some boundaries.
Option 1.
If you are developing your app for customers, pick one minimum resolution (like 1024x7678), redesign you dialogs so that everything fits. Maybe break up some into several, or use tab strip control.
Option 2.
Create separate dialog forms for each resolution you'd like to support, but use the same class to handle it. At runtime detect resolution and use the appropriate form.
Option 3.
Write your own resizing functionality, so that user could adjust the size of your dialogs to his liking.