I am using a custom item renderer with an image and a line of text. I have the image set to blendMode="luminosity" and when you run it on the desktop air to debug and test it it appears to run perfectly fine without any lag. However if you test it on a mobile device it causes the list to lag a ridiculous amount to the point where it is unusable. If I do this on just one item of the list it will cause the lag to appear. It gets worse the more images there are that use it but even with just one it is clearly evident and practically unusable.
Does anyone know if there is a way to improve the performance of this or is there no work around?
Thanks
Related
Our app loads extremely slowly, especially the pictures, and the developer has not been able to come up with a solution to this. The movements are slow and the buttons are slow in response (works on the 2nd or 3rd press).
The stability is terrible, for example the whole screen moves to the left by 2mm when you press a back button.
The app downloads information from the server every time it runs. We have tried changing the server, but this did not yield any results.
The current solution is to make the images smaller (compress them) to make the app run faster, but we are dubious if this will work.
Is there anybody who has had the same problems with their app?
I would be very grateful for any suggestions for how to fix this. We need it to be fast and responsive.
These are very vague, general issues. You ideally need a developer to take a look at the whole problem.
Some things they may look into would be:
Is data access asynchronous?
Are there transitions running on the
page?
Are styles being added on hover or focus?
If the app is written badly, simply chucking more resources at it probably won't solve the problem.
I am developing a program that needs two full screen Direct3D dispalys. According to the documentation I should create the swap chains in windowed mode and then switch to full screen mode. While this works fine on Windows 8 (currently I'm just using Alt-Enter to do the switch), it does not work on Windows 7. On Windows 7 I get a problem similar to this issue where the screen that has most recently been switched to full screen works fine, but the other screen, which was previously working just fine in full screen, goes black (and stays at the same full screen resolution) until I take it out of full screen.
You can find my mess of a rough prototype at this tag.
Apparently there have been other bugs relating specifically to Windows 7 in the past... But I appear to be getting an issue that is slightly different.
Also, I have tried disabling DWM Composition like suggested in the linked question, but that did not do anything to resolve the problem..
Please let me know if there's any more information I can provide about the issue... I guess worst case scenario is I simply fall back on DX9 which apparently works fine for multi-monitor full screen setup...
I think I may have figured out the cause of the problem: It may be because I was creating multiple ID3D11Device for the same Adapter.
My code was overly complex for what I needed as I was following techniques introduced in this article when I really didn't need anything more than a single thread for all windows and rendering. After sharing the same ID3D10Device for each Render Target (one Render Target per Output, one ID3D10Device per Adapter) I have successfully got DXGI with DX10 rendering two full screen displays as shown in my rough memory-leaking proof of concept.
Since this was my first time working with any of this tech, I used this article to help me along with this process: Display Different images per monitor directX 10
I have a webapp for iPod touch and iPad. Works like a charm on iPad 1 and iPad 2. Now I have tested on a new iPad (iPad 3, iPad HD whatever name to be used) and I see that the painting of the screen is slow. I can see kind of blocks being painted one by one.
Anyone knows how I can get the painting of the screen faster than iPad 1 and 2 instead of slower ?
EDIT: Bounty expiry
The bounty has at least given some answers, although they are not sufficient to award the bounty. The question remains open.
We had similar problem in our application, and tried some optimizations, here are the two most effective approaches:
Avoid using CSS3 effects. We used a lot of CSS3 shadows in previous versions, which slowed down rendering process on iPad 3 a lot. After replacing those shadow effects with background images, performance got greatly improved on iPad 3.
Optimize Javascript. Our application has some scrollable components, whenever user scrolls the component some Javascript code will be executed to do some loading work, like loading images in a lazy way. On iPad 3 scrolling will delay for 500ms when user tries to scroll from one page to the next. Then we found some unnecessary image loading work were performed in the scrolling callback, after removing them, the scrolling performance is acceptable.
These two approaches may be quite specific to our application. Hope they can help you as well.
have you checked viewport in your meta?
I am using
<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1″>
I didn't feel any performance overhead. Perhaps some parts of your webapp hit on the weakness of web view.
You may start commenting your HTML until you find your webapp go smooth.
I have updated a New iPad (iPad 3) with iOS 6 and I do not see the rendering problem any-more. I have seen in several articles that the speed of Safari has significantly increased. This performance gain in iOS 6 is solving the problem for my web-app.
As the iPad's we use are dedicated for the web-app, I will recommend iPad 3 only with iOS6.
Thanks for the posts and answers !
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.
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