Apple site says iPhone 5 Display is 1136-by-640-pixel resolution at 326 ppi. Generally resolution is practically spelled (Width x Height). In the iPhone 5, case we know 1136 is height and 640 is width when we hold the phone in portrait mode.
I am working on one Android project now I got confused with these mobile device resolutions. My app is targeted only for portrait: 1280x720, 960x540, 960x540, 800x480, 1920x1080, 1280x720, 1280x720, 1280x720, 960x540, 960x540
My questions are:
When we say 1136 x 640 which mean width x height of the device in landscape mode - correct?
Is it good idea to design the mobile App targeting just one resolution 320x480 (portrait only) and force the device to run in that 320x480 resolution? The library that I am using has the support for fixed resolution mode, and it's called as "Design Resolution" which accept (wxh).
To answer the first question: Yes, when Apple says 1136-by-640 pixel resolution they mean width-by-height in landscape mode.
To answer the second question: While it is not recommended that you design an app to only work in one orientation (portrait mode, for example), it is acceptable if that is what you need for your app. See the Apple Human Interface Guidelines. They say that if you do choose to support only one orientation, make sure that you also support that orientation when the device is turned 180 degrees. That is, make sure it flips when the user turns the device upside-down.
As for forcing a smaller resolution than the device is capable of displaying, that is never a good idea. See the Android Core App Guidelines which say that you should use the whole screen, and also suggest you support both orientations if possible.
I would say it's acceptable practice to develop an app for only one orientation, but force the orientation in the layout or code so when the user rotates the device it doesn't break the layout. When considering different screen resolutions you'll want to take into account possibilities of all your potential users. If you know the device resolution is going to be the same across all devices, by all means only code for that. If it will change you'll want to account for all. Since you're using portrait the resolution would be noted as 640x1136. It looks like your minimum target is 480x800 and max is 1080x1920, so I would suggest setting up emulators on all 3 sizes, and testing accordingly.
There is no way to change the actual device resolution (except if you are using a crt monitor). That said, if you design your app for a fixed resolution, then your code (or a library) should scale/crop your design to fit to the actual screen.
Keep in mind that scaling down will give you descent image quality but scaling up (to a higher resolution) results to pixalation (pixels showing up as squares).
On the other hand, scaling uses cpu (or gpu) and higher resolutions need more processing power.
So depending on your app you should choose a resolution that doesn't seem too bad on high resolution devices and can still perform decently on low processing power devices
It would be nice if you gave more information about the library you are using.
Latest Android layout editor for eclipse provides the possibility to see you screen as it would look in all screen sizes. If you want to develop for single resolution only and stay intact in other screen sizes, you should not use fill_parent and match_parent, use wrap_content instead, so your elements stay same size. Do not use dynamic placement of elements based on screen size.
If you want to support other screen sizes then you would do the opposite of what is mentioned above.
Related
I am having a problem, or perhaps I am confused.
I have a laptop connected to an external monitor with a resolution 1680x1050. In the windows settings, it is recommended a sacale of 100% but for me it all too small, text in the internet browser, file explorer... and so on.
So I set in windows a scale of 125%, for me it is a good sacle. The problem is when I am designing the WPF windows, I have less space than the real space, I have 25% less space. So when I depploy the application, some users have a 1080p monitor, so they see a lot of empty space.
I am wondering if there is some way to adjust the size of the controls to the real space, no matter if the user set scale in windows or not.
I was thinking if there is a way the application detect the sacale that user set in windows and then in the WPF, apply the opposite scale, for example, if the user has a 125% in windows, WPF should to reduce the sacale 25% (more or less, theory it would be a little more) until 100%.
Or perhaps there would be a better option.
In sumary, I would like for example design my application for example for 1080p, and no matter if the user sets scale or not in windows, I would like to the application in a proportion that fit to the view for a 1080p monitor with no scale. Supposing that the user has a 1080p monitor too, but with scale.
Thanks.
EDIT:
I have tried to use an application manifest in my WPF Core project, and in the properties I have set it as resorce, I uncomment this code:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
</windowsSettings>
</application>
It seems it should be to help, But in my case I still have the same behaviour, in my monitor with 125% of scale in windows, I have less space.
I have a very weird bug that I just can't understand.
I am currently using the WPFMediaKit library in one of my programs.
When using the library in a near empty new "demo" wpf solution, the image from the USB Camera source is rendered perfectly to the MediaCaptureElement class.
However, using a more complex solution, the same library (without changes), the frame gets rendered black. I can see there is connection to the camera and everything goes well, DirectShow graph is built normally and everything just looks fine, besides the black frames. I can even open the camera properties and see it pushing out frames as usual.
Also, this only happens on Dell E6540 (With an AMD and Intel HD gpu) if it's Windows 7. Windows 8/10 work fine. Have tried a lot of drivers nothing seems to change the output.
I have no clue what to do or what to try.
After many hours and just after deciding to post this question, I found the answer.
The more complex solution, under the AMD Settings application was set to use "High Performance" mode, this mode was automatically enabled on Windows 7 for some reason. Disabling that and setting it to "none" or "lower power" fixed the issue.
Doesn't change the fact that there is an issue with laptops with dedicated AMD GPUs, probably something to do with DirectX/Direct3D which is used to render the frames.
I grabbed this multi window test code, changed it to use D3DXCreateTeapot instead of D3DXLoadMeshFromX (I couldn't find a teapot.x file), moved the EndScene call below the DrawText call and set NUM_WINDOWS to 1. With those minor changes, the test works and creates two windows, each with its teapot.
I built the test and deployed it in a machine which has an Intel HD Graphics onboard GPU with two heads, each attached to a monitor. Then I moved one window to each monitor, and enlarged both windows to take up about 80% of each monitor space.
With this setup, which is quite close to what my app needs, the window in the secondary monitor always goes too slow. If I swap the windows, it's the same: the one in the secondary monitor starts crawling, and slows down the whole system.
I googled around and some sources (albeit dated) state that only the primary monitor can use hardware acceleration when not in fullscreen mode. I cannot use fullscreen because direct3d9 rendering in my app is done inside a user control embedded in a Winforms GUI.
Is it really impossible to get hardware acceleration for both monitors in windowed mode? The legacy version of our application uses MFC + DirectDraw and manages to perform fast enough, but those are obsolete technologies and we'd abhor going back there.
You have 3 options:
Try many combinations, like: D3DPRESENT_INTERVAL_IMMEDIATE +
(D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_COPY) +
D3DCREATE_ADAPTERGROUP_DEVICE. Maybe some will offer better
performance.
Render to a surface, convert to a bitmap, and use it like any other bitmap in your form. Something like this
D3DXSaveSurfaceToFileInMemory.
Change your code to DirectX11. You have more options for GDI interaction there. Better rendering behavior. Maybe better drivers.
Some years ago, I made some multiple window code, also multiple device, using DirectX10/11. I can't tell about DirectX9 having this issue, seems absurd to me, but could be your Windows version, or Intel driver.
I need to create a small notification in the right-bottom corner of the screen. It should provide the following functionality:
Should NOT change the current focus.
Should allow me to put some text in it.
Should appear (and stay if possible) on top of all windows.
Can you suggest using something? The less installing required the better.
Well, there are a few ways to do it.
Roll your own
Use the infrastructure of the desktop environment
Naturally, #2 is going to be more reliable — if you know what the desktop environment you're targeting is.
You mention Linux, so let's look at Gnome. The two most popular (?) Linux-based operating systems are the Red Hat/Fedora/CentOS family and Ubuntu, both of which are based on Gnome 3.
Gnome 3's Notifications;
Do not change the keyboard focus
Allow text (and more)
Appear for a moment above other windows, but then tuck away at the bottom of the screen after a bit; but, can be called back up by mousing over their icons.
Plus, there's nothing to “install” — unless you're running an unusual build, the stock distributions all include the Notification support you want already.
The documentation is found on the Developer.GNOME.org web site, here.
If you are not running on a “normal” Linux distribution, you still have options.
Install libnotify, and enough Gnome infrastructure to let it work.
Re-inventing the wheel…
In the latter case, you'll want to:
Create a top-level X Window;
Set flags on it to ask the Window Manager to please* keep it on top, not decorate it
with the usual resize and title decorations, and so forth;
and set up its contents on your own.
Some documentation on providing hints to the window manager can be found on FreeDesktop.org.
*- the window manager, however, is free to ignore your hints, if it chooses.
We have an old (Win32) and new (WPF) version of our blotter software, which the traders are currently running side by side. However, running the WPF application often severly slows down the redraw rate of the Win32 application.
Without the WPF application running (or minimized), draw rate is fluid and fast in the Win32 application. With the WPF application open alongside it, the Win32 appl's UI draw rate slows down noticeably. Running the WPF application seems to trigger use of some resources which are taken away from the Win32 app (both graphics-heavy) - causing the slow down it seems.
CPU and Memory are not anywhere near being saturated, so it doesn't seem to be related to those. Lowering resolution and/or reducing the number of monitors to display on (therefore decreasing video card memory usage and bandwidth load) makes no noticeable difference, therefore it doesn't seem to be a graphics hardware performance issue either.
One hypothesis that may explain the cause is as follows:
Under the hood, we know that both the WPF and Win32 applications output graphics information to a windows "message pump" which is basically a queue of instructions of what to draw to the screen. It seems as if when the WPF application is not running, the Win32 has full unfettered access to this and screen updates are fluid. Running the WPF application alongside it puts additional messages on this queue, so Win32 application has to compete harder for access to it (in order to do each screen element update), therefore "clogging the pump" giving the effect we see.
If the above is the case, can anyone recommend approaches to manage/control the window message pump in order to prevent this happening?
The flicker is the type you typically get when resources run low, where you can see individual elements (forms, labels) flicker and gradually draw on to the screen.
If anyone has any suggestions/ideas, let us know.
Each process will have its own message pump - this is not shared.
If you are not seeing high CPU utilization, then WPF is using hardware rendering, so it could possibly be GPU saturation. Can you get information on GPU utilization?
The following post details methods of getting GPU utilization:
Programmatically fetch GPU utilization
Okay, I think we've found the cause, and fix. In a nutshell, hardware and software accelerated windows don't play nice. Using software-rendering across the board fixes glitches that were previously there when running hardware-accelerated windows. Since our legacy Win32 app will be decommissioned soon, this is a workable comprimise - we can simply switch hardware acceleration back on when we drop the legacy application.
Notes below:
It seems like this issue is being caused by running a traditional software-accelerated 2D application (X) and 3D hardware-accelerated WPF one (Y) at the same time, and is a graphics driver issue.
Forcing Y to run in WPF software-acceleration mode as well causes little degradation in scrolling performance (as the bottleneck is still the grid's internal layout code).
However, what it does do, is get rid of the slow drawing issue in X, because Y is now running as a software-accelerated 2D application, like all other Windows applications on trader's machines. This explains why no applications other than Y caused slowdown - it seems as if software and hardware-accelerated graphics applications don't play nice when run at the same time.
This makes sense - when I play a hardware-accelerated game, for instance, I've seen similar (where the desktop redraws very slowly when switching to/from the game between hardware/software acceleration modes).
Thankfully we can turn off hardware-rendering without much impact in performance. Once X is decommissioned we can switch hardware-acceleration back on for the minor benefits it provides in Y (support for smoother animations and heavier use of fill gradients without slowing down etc).