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.
Related
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.
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.
I'm currently trying to determine the available disk space from my Silverlight application.
My app can download a lot of data (video files) and obviously, this can fail if the disk space isn't there.
I know I can catch exceptions on writes, but that will not lead to a very user-friendly experience, because the information will come too late and cause useless waits.
In regular .NET, I would be using DriveInfo (see How do I retrieve disk information in C#? for an example), but that class isn't present as of Silverlight 5, even in elevated trust mode.
So, is there a way to determine the available space on a drive in Silverlight?
Update:
I'm fine with requiring Elevated Priviledges for my application.
I'm also fine with Silverlight 5 only solutions.
I need something that works on both Windows and Mac OS, so PInvoke/COM interop is not an option.
There has been filebrowser demos out there written in Silverlight but they would run with elevated trust.
That means that you would have to make the user immediately suspicious of your application when they first run it.
It's probably a better user experience to just have a well worded error message for when the user runs out of space.
Another option would be to try an increase the isolated storage quota by the size of the biggest video available.
http://msdn.microsoft.com/en-us/library/system.io.isolatedstorage.isolatedstoragefile.increasequotato(v=vs.95).aspx
Then when that fails just let the user know that no more space can be allocated for the app had that he may need to delete older videos.
I'm adding my answer here to sum up my discoveries:
TL/DR: there is no easy way to get available disk space in Silverlight 5 that is cross-platform (Windows/Mac OS).
You can't get available disk space with standard Silverlight calls. DriveInfo is missing from Silverlight 5, elevated privileges don't come into account here.
Quota is useless for that kind of issue, it doesn't take into account available disk space.
There are workarounds for Windows only, requiring elevated trust, using P/Invoke into Win32.
For a detailed support of filesystem, see this article: http://www.codeproject.com/KB/silverlight/FileExplorerInSilverlight.aspx
Fall-back is to check for exceptions when writing files and present the user with a message at the time of writing. People have also suggested pre-writing the file when the download start to ensure sufficient disk space.
Here is the situation. The company I work for builds this piece of software in c that can make a Windows computer act a bit like a TV. Essentially, our piece of software is meant to be played full screen and content is displayed from the internet without the user having to ever touch the computer again.
The problem is that once in a while, the system brings up pop-ups like "Your Windows system is ready for an upgrade." or "Please renew your Norton subscription" etc. which the user has to periodically and manually remove.
Is there a way to display content full screen without being bothered by those warnings?
Yah, whether or not the development community agrees, Microsoft has several standards for when and why it might be acceptable to have exclusive use of the monitor.
The most official strategy is to use DirectX in exclusive mode. This is what games do, what windows media player does in full screen video with hardware acceleration enabled, etc... If your application is multimedia intensive (as suggested by TV like functionality), you should probably be using DirectX too. Besides giving you the exclusive display access it will also increase your applications performance while lowering the CPU load (as it will overload graphics work to the video card when possible).
If DirectX is not an option, there are a great number of hacks available that seem to all behave differently between various generations of windows operating systems. So you might have to be prepared to implement several techniques to cover each OS you plan to support.
One technique is to set your application as the currently running screensaver. A screensaver if really just an EXE renamed to SCR with certain command line switches it should support. But you can write your own application to be such a screensaver and a little launcher stub that sets it as the screensaver and launches it. Upon exit the application should return the original screensaver settings (perhaps the launcher waits for the process to exit so that it returns the settings in both graceful exits and any unplanned process terminations ie: app crash). I'm not sure if this behavior is consistent across platforms though, you'll have to test it.
Preventing other applications from creating window handles is truly a hack in my opinion and pretty bad one that I wouldn't appreciate as a customer of such software.
A constant BringWindowToTop() call to keep you in front is better (it doesn't break other software) but still a little hack-ish.
Catch window creation messages with a global hook. This way you can close or hide unwanted windows before they become visible.
EDIT: If you definitely want to avoid hooks, then you can call a function periodically, which puts your window to the top of the z-stack.
You could disable system updates http://support.microsoft.com/kb/901037 and remove the norton malware.
You could also connect a second screen so that the bubbles appear in the the first monitor.
Or you rewrite it for linux or windows ce.
One final option is to install software that reconfigures your os into a kiosk http://shop.inteset.com/Products/9-securelockdown.aspx
If you don't need keyboard or mouse input, how about running your application as a screensaver?
A lot of thoses messages are trigged/managed by Windows Explorer.
Just replace it with your dummy c#/winform.
By changing the registry value
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="Explorer.exe"
You can specify virtually any exe as an alternative to explorer.exe
That's the way all windows based (embedded) system (ATM & co) do.
There's still few adjustment (disable services you dont need / dr watson & others), and of course, you'll want to keep a "restart explorer.exe" backdoor.
But that's a good start
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).