In Vista and later, if an app becomes unresponsive, the Desktop Window Manager is able to handle redrawing it when necessary (move a window over it, drag it around, etc.) because it has kept a pixel buffer for it. Windows also tries to detect when an app has become unresponsive after some timeout, and tries to make the best of the situation -- I believe it dims out the window, adds "Not Responding" to its title bar, and perhaps some other effects.
Now, we have a skinned app that uses window regions and layered windows, and it doesn't play well with these effects. We've been developing on XP, but have noticed a strange effect when testing on Vista. At some points the app may spend a few moments on some calculation or callback, and "if a message has not been retrieved within 5 seconds, the DWM declares the window to be hung" (MSDN - Preventing Hangs in Windows Applications). It seems that when this kicks in, a strange graphical problem occurs: any pixels that would be 100% transparent due to the window regions turn black, which effectively makes the window rectangular again, with a black background. There seem to be other anomalies, with the original window's pixels being shifted a bit in some child dialogs.
I am working on reducing such delays (ideally Windows will never need to step in like this), and trying to maintain responsiveness while it's busy, but I'd still like to figure out what is causing it to render like that, as I can't guarantee I can eliminate all delays.
Basically, I just would like to know what Windows is doing when this happens, and how I can make my app behave properly with it. Skinned apps have to still work on Vista and later, so I need to figure out what I'm doing that's non-standard. I don't even know exactly how to look for information into how Windows now handles unresponsive apps, as my searches only return people having issues with apps that are unresponsive, or very rudimentary explanations of what the DWM does with such apps. Heck I'm not even 100% sure it's the DWM responsible, but it seems likely. Any potential leads?
Photo of problem; screen shots won't capture the effect (note that the white dialog's buffer is shifted -- it is shifted exactly by the distance it has been offset from the main (blue) window):
This is standard behavior; you can also notice it in Office 2007 / 2010 when they freeze.
I have found that it is called 'ghosting' when it does this, and it was introduced in XP (though it seems DWM takes it a step further since it keeps track of every app's pixels). It is possible to disable it for the duration of your app's life with DisableProcessWindowsGhosting(). Some folks say that it is not recommended, but considering how badly it plays with layered windows, the downsides of turning it off are negligible. I've tested it and it does precisely what it claims; now if the server takes a little longer than expected to return, it won't mangle the entire interface.
If there is a better way to get my layered windows to work with Vista/7's handling of ghosting without disabling it outright, I'd certainly still be interested, but I'll probably just accept this as the answer otherwise.
I think there are basically two things that will help with this:
First, like you've been doing, try not to hang in the first place: do as little heavy lifting in UI threads as possible.
Second, don't use multiple top-level windows to implement what the user is meant to see as just one; instead, do the compositing yourself. That will prevent the layers from being moved out-of-sync from one another.
Related
Well, the title almost says it all : Why should I not move a GUI (e.g. Gtk) window on screen from the code ? In Gtk 3 there was an API for moving windows on screen, but it was removed in Gtk 4, because it is not good to move a window from code; only the user should do so (don't ask me to provide sources for that, I read it somewhere but have forgotten where and cannot find it). But I cannot think of any reason why it shouldn't be good, but of several reasons why it could be good, for example to restore the position of a window between application restarts. Could you please shed some light on this ?
The major reason why is that it can't possibly work cross-platform, so it is broken API by definition. That’s also why it was removed in GTK4. For example: this is impossible to implement when running on top of a Wayland session, since the protocol doesn't allow getting/setting global coordinates. If you still want to have something similar working, you'll have to call the specific platform API (for example, X11) for those platforms that you want to support.
On the reason why it’s not supported by some display protocols: it’s bad for UX and security. In terms of UX: some compositors can have special behavior because they need to work on a small device, or because they have a kiosk mode in which everything should always run fullscreen, or they provide a tiling experience. Applications positioning their windows themselves then tend to give unexpected behaviour. In terms of security: if you allow this, it’s technically possible for an application to reposition and resize itself so that it covers your screens while making itself transparent, without it being noticeable, which means it has the possibility of scraping all input.
I am debating whether to hide or not to hide the system tray in a Windows Phone 7 application. I've not found any general suggestions on this issue -the official Windows Phone design guidelines don't address this issue at all - except for Jeff Wilcox's blog post who suggested that he personally likes to see the system tray in applications. I'd like some general advice on this issue from other Windows Phone developers.
Some reasons for showing the system tray are
Doesn't take up that much space
Users may want to see it at times
Reasons for hiding it are
You can't control its background: unless you're using PhoneBackgroundBrush as the background the top row will stand out
Lots of widely used / official apps already hide it: all games as well as the official Facebook and Twitter app.
I'd appreciate all advice on this.
Transparency and colors are now possible with Mango by setting its BackgroundColor and Opacity :
shell:SystemTray.IsVisible="True"
shell:SystemTray.BackgroundColor="Transparent"
shell:SystemTray.Opacity="0"
I would say by default show it unless it really gets in the way in a way you can't workaround, especially if its an app and not a game.
I would say it depends on the application/game you are writing
If the app needs a network connection or if you will be in the application for a long period of time show it so the user can keep an eye on network and battery.
If you need the extra screen space (for a game?), and you rarely need network hide it.
Or... I guess you leave it up-to the user and give them a setting to programatically hide/show it.
I think its best to use the tray in applications that are tools or utilities. Typically these users would prefer more info than less when they're using applications on the phone (battery, network, time).
Also adding the tray in there tends to make the application look more native on the phone (according to me and others I've asked), which is a big plus because the user associates your app as if it was built with the phone OS.
But if the application is a game, media, etc. type of application I recommend you take it off, especially on panorama because it takes away from the intended design. Also these types of applications focus on the content and seeing multiple little icons at the top can take away from the experience.
Really to me the space it occupies isn't really THAT much, so that shouldn't be too much of an issue. But rather the purpose of the app as stated above.
I do like the suggestions that have been given as far as giving the user the choice. Check out this code:
bool ShowTray;
//ASK USER WHAT THEY WANT
//ShowTray = true or false;
SystemTray.IsVisible = ShowTray;
I've been reluctantly hiding, at least on any view where I have a background image; otherwise it looks too strange to me. I've been considering a setting in my app that would allow the user to choose, and persisting that to isolated storage.
Also considering maybe having the top of the screen in phone background brush color and have it fade / blend into another color or background image. Not sure how well that would turn out but as long as it is not a cheesy looking gradient effect, perhaps.
I'm hoping eventually MS will soon add support for transparency in the system tray or otherwise help address this issue. As a user I wish that I could force the system tray to always be visible across all apps, but as a developer I realize that the visual effect often doesn't look good.
Perhaps if the community came up with a new UX metaphor where maybe double-tapping in the system tray area would toggle whether it is visible. A single tap could perhaps start to animate / pop / hint at the system tray...
As we know, several modern applications (IE9, Firefox 4, Chrome, Paint.NET, etc.) use DwmExtendFrameIntoClientArea for the Aero glass effect.
What type of applications should you really use this for, though? For browsers I can understand minimizing as much extraneous space as possible, but really, what's the point? Why not just create the window without a frame (like Google Chrome does when DWM is not present)? I'm just looking for some rough guidelines on what type of applications should use this effect and when.
Well, as this is purely a visual eye-candy type of thing, you're asking more for subjective opinion than anything else. First, check out the Windows User Experience Interaction Guidelines, though.
Personally, I like Outlook 2010, where the tab labels are on a glass background - I like the background image on my desktop (or windows behind) seeping through. I think it gives the impression that the window is not taking up quite so much of my workspace. I also love Chrome and it's use of glass for tab space.
I don't like windows media player where the controls are on glass - it makes them seem busy on a busy background. I also don't like the Add Gadget window, where the whole thing is glass (although more blurry) for the same reason.
So pick your design ideals and keep it consistent. My personal pick is to allow glass to come in on windows aspects that are mostly text and uniform, and not the main focus of interaction. On things that are "busy" and are high interaction areas, I dislike having glass behind.
I have a windows application that scrapes pixels from the screen for recording (in the form of a video) to a custom screen-sharing format. The problem is that on machines using a software cursor, blitting from the screen with SRCCOPY|CAPTUREBLIT (so that layered windows also show up in the image) causes the cursor to blink, as described in Case of the Disappearing Cursor.
For single screen shots, this is not a problem, but when multiple screen shots are taken in rapid succession, the cursor blinks so fast that it sometimes seems to disappear altogether.
I have looked into using the Windows Media Encoder SDK (as described in a codeproject article, see below) because it doesn't cause the cursor to blink, but there seems to be no way to directly access the frame data. Unfortunately, both real-time encoding and the custom format are both requirements, which makes windows Media Encoder unusable for this purpose.
I have also tried the DirectX way (described in the same article, see below), and it seems to suffer from the same problem.
Has anyone else run into this problem? There must be a way around it - many commercial screen sharing programs have no such problem.
article: www.codeproject.com/KB/dialog/screencap.aspx
you can use Magnification API in windows vista or later.
i cannot find a good idea in windows xp.
What about using a mirror driver?
You are right, a mirror would certainly work. However, at the moment, I am trying to stay away from that approach because of the security and permissions concerns when installing under a user without admin rights. Correct me if I am wrong, but I don't think there is any way to install a driver without such rights. Besides that, it seems that that would be needlessly complex: there should be a simpler / less invasive way to do this. (I should have mentioned this in my original question)
Just copy the screen and the cursor separately and overlay them.
The thought I had to overcome the flicker is to "manually" draw "your own copy of the mouse", then make the BitBlt call, or to call BitBlt with just SRCCOPY then manually capture any visible transparent windows over the top of it. I don't know how the commercial stuff does it (or the windows media encoder apparently does).
ref: http://us.generation-nt.com/xp-bitblt-captureblt-option-help-26970632.html
Up to now I been using the pda emulator in visual studios 2008 (I am using windows mobile 6.1 professional sdk).
So I just dragged and dropped most of my GUI components into the form. In one instance I made a panel then in this panel I dynamically generated labels in it with certain location positions.
I then put it on my Hp PAQ 110 Classic pda and it looked fine and everything. Then I was looking through the emulators one of them was called professional square. So I decided to run it and when it ran my program it looked like crap.
I had missing labels, missing controls and it just looked horrible.
I thought maybe it would like do some resizing for me but it seems to either did a shitty job or it does not do it at all.
So how do you make a GUI that will work well on all mobile phones(or at least the vast majority of them).
Is there like X number of types of mobile phones? Like the emulator emulates a pda and it works on my HP one so I am assuming that all window mobile device pdas have the same screen size.
Then the next question is how do you make the controls position properly from one device to another? I heard of people using XML files that have all the location position, sizes and etc that they call up and I guess essentially generate the GUI dynamically based on the information in XML.
But I could not find any examples how the XML file would look like, how to detect what phone type it is so that I could call up the right node of the file for that phone.
I am not sure if there are any other ways but this seems better then a set of GUI forms for each one.
Also would it be recommended to have most things in a panel so that way even if the stuff is bigger you can at least turn auto scrolling on.
thanks
I spent a good amount of time looking at different solutions for this problem (see my question here as well) and ended up with a pragmatic approach - consistent use of docking. You have to restrict yourself to the least common denominator, i.e. the lowest resolution you want to support, in terms of how much you can fit on the screen. The good news was that grids always use the entire available real estate, and my forms flow correctly on all devices and the screens don't look like they are broken.
This is far from being an easy task. You can follow some guidelines, but the only thing that will actually work is to always test the User Interface in all possible screen resolutions. Emulators are a good way to start, however it will be better to have an actual device. Some things like font sizes and text readability can only be tested in a real device. So, these are my advices:
Try to use docking for positioning your controls.
You need to be able to handle orientation changes correctly. Using docking helps, but again you always need to test in different screen resolutions.
At some point you will find out that it is inevitable to detect the screen size and adapt the User Interface dynamically. I don't agree that you should restrict yourself to only display what can fit in the smallest screen. A professional application should adapt itself to the available screen size and take full advantage of it.
Structure your application so that it is easy to support new screen resolutions. Make the main User Interface code screen size agnostic. Make it get all information about dynamic resizing - positioning from a configuration class. This way you only need to enhance a single item in your code in order to support a new screen resolution.
And of course:
Test in all possible screen resolutions. After even a minor change to the User Interface, retest.
Eventhough the above posts where helpful this video I found solves all my problems and you don't have to develop for the the lowest screen.
http://www.microsoft.com/events/series/detail/webcastdetails.aspx?seriesid=86&webcastid=5112