I have a WPF application in which I'm using SoundPlayer to play several short sounds such as keyboard clicks. Sometimes, seemingly at random, the sounds will stop playing. When I navigate away from the page the sounds will then play all at once in one screeching playback.
My question is, are there any obvious reasons as to why this would happen?
I've tried several things but because I can't consistently reproduce the issue it's hard to find the cause. The sounds are used throughout the application, so I load them in app.xaml.cs into an application scoped static collection. I call SoundPlayer.Load() to ensure they're loaded into memory straight away.
Like I said, this never stops working completely. The play backs seem to pile up until navigating to another page where they all play at once.
One other thing that may have an impact is that I am displaying a webcam feed in the application. The webcam feed is loaded using the DirectShow.NET library. I'm not sure if loading graphs can have any adverse effect on the playback of sound.
I suppose the web cam is updating a UI element which will cause the UI thread to be pretty busy, in that case you probably do not want to use SoundPlayer.PlaySync() or SoundPlayer.Load which both block the current thread.
Instead try SoundPlayer.LoadAsync() and SoundPlayer.Play() which use a separate thread.
Related
I'm working on an app using geo fences but I'm hitting some issues.
I've been testing on Android predominantly so far.
a) I set up the geo-fence and it triggers fine for enters and exit events.
However, after an extended period time (such as a few hours or overnight) the events stop until the app is opened again.
b) My other issue is the geo-fence exit seems to trigger even when I haven't moved at all, and definitely not outside of the radius (150 meters).
I've looked at https://www.codenameone.com/javadoc/com/codename1/location/Geofence.html, and my code is very similar to the example.
Are there any other build hints I need to make it more accurate and persist in the background?
Geofencing should only be added once, it's a very flaky API in the native OS especially when it comes to background behavior that breaks frequently with OS updates.
Use something like:
if(Preferences.get("AddedGeofence", false)) {
addGeofenceBinding();
Preferences.set("AddedGeofence", true);
}
And see if this works.
I built this app that takes pictures, displays them for acceptance and uploads them to a webserver via post.
It is very simple in concept and execution. But then the app is freezing in the Android handset (I have an Xperia Z3+ which i has a fairly good amount of resources, also tried in a Moto X).
To try and reproduce this I take a picture (it will automatically tried the upload)... push the power button for the screen to shutdown... then when I light up the screen it takes a while for the app to start working again (I can see because I have a background animation). After some retries of these... the app will freeze and I'll have to close it to retry.
Any suggestions on how to troubleshoot this problem?
My thinking is that I can aliviate the problem a little by removing the animation elements from the screen... at least the perceived performance will be far better is the app does not appear frozen on any app switch... therefore I want to be able to use the onPause, onStop from the activity lifecycle events to clear the animations. I guess those objects are serialized, so I will save serialization and deserialization time and also the perceived performance will improve as no freezed app will be seen while the onResume, onRestart events.
Is this posible?
Thank you very much
Chuck
This isn't caused by the animation, it may be caused by an uncaught Exception or poor app performance.
To review your app performance, move any long process that requires feedback to the UI (AsyncTask) to postShow() method of your forms and not beforeShow(). If it doesn't require feedback to UI in real time (IntentService), consider using Display.getInstance().scheduleBackgroundTask() which runs your task on a low priority thread while serializing it and this can be done in the beforeShow() method. If your forms are handcoded (Not GUI), do heavy long process in addShowListener().
Also cut down the amount of images you use in your app as this could also hinder your app performance when loading heavy images.
Avoid unnecessary use of revalidate(), usually by not calling it in a loop, it's a bit expensive, use repaint() instead.
You can also use Android ddms to check if your app is running into some errors.
Locking your screen or minimizing shouldn't affect your app in anyway other than when the app is starting up and the splash screen is shown (This usually freezes the app if you minimize your app when splash is shown). I believe this is a known issue though.
Another option could be the "suspend-resume" behavior. When an app is suspended (power button, incoming phone call etc.) the stop() method is invoked followed by a call to the start() method when it returns.
If you have a progress indicator during the stop() method then the restore call will reshow the progress indicator with the previous form as its "before form". That way when the progress indicator is dismissed it shows the "previous form". You can test this behavior in the simulator using the "suspend/resume" menu.
To workaround it just dispose the progress indicator in the stop() method as such:
public void stop() {
current = Display.getInstance().getCurrent();
if(current instanceof Dialog) {
((Dialog)current).dispose();
current = Display.getInstance().getCurrent();
}
}
I'm having the well documented problem of StageVideo killing Stage3d, or at least overlaying a black layer above the Stage3D on mobile.
I've attempted some of the various solutions offered around the forums, including moving the viewport off screen, assigning the netstream to a normal flash video before closing. None of these seem to help.
Adobe's answer seems to be that is is working as it's designed and it's not a bug, specifically:
When using Stage3D, the user must call Context3D.present() to make the stage layer update. There is no independant update of the Stage, Context3D.present() drives the update of both the Stage and the Stage3D layers. This is necessary to achieve high performance. Workarounds include making all the Stage3D invisible and delaying the Context3D creation until you are going to start using it.”
From https://bugbase.adobe.com/index.cfm?event=bug&id=3186454
Away3d seems to use Stage3D managers in the core, and there is a present() function, which contains the important Context3D.present().
I'm having trouble trying to initiate this call, but can't see a way to access it.
Does anyone know if this is likely to work, and what the call might be?
I got around it by using a native extension https://github.com/freshplanet/ANE-Video/
I have a WPF application that is doing some serious work (doing some calculations) when a button is hit. I wanted to add a 'busy animation'. However, the application is so busy doing its work that the animation is stopped until the calculations are finished.
The serious work should always be handled in a separate thread otherwise the complete user interface may be blocked. So you are unable to click anything and not even close the application.
If it is possible you should also try the make small chunks of work and give the rest of the application time to "take a breath" and not do all work at once. It's not always possible but some work can be managed that way.
Are you running your "serious work" in the UI thread? If so, you need to move the work to a separate thread if you still want the UI to be updated.
I have developed WPF Application. In that application iam loading 200mb photos to the listbox.After that Iam adding those images to canvas.While adding photos to canvas after sometime (i.e; after adding 10mb images)iam getting Some error like ----
*****The CLR has been unable to transition from COM context 0x10b46f0 to COM context 0x10b4860 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.*****
Is there any way to increase the performance of my application. I need a solution for this problem.
Any Suggestions for this.
Don't load all 200 mb of photos into the listbox all at once on your UI thread. Will the user be looking at 200 mb all at once? It'll take some work on your part, but you're going to need to do some delayed loading of the images from a background thread.
Take a look at this article (Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps), it may help.
This looks like two questions, the first is that you are loading images in a background thread, but not doing it correctly; thus, the COM error. Double check that you are have a STAThread application and that the image loading thread is not interacting with the WPF dispatch thread incorrectly. Here's a discussion MTA vs. STA; however, WPF needs STA, and it's a loosing battle to fight it.
The second question seems to be how should one do this; that is, loading a bunch of images for display. I would look into using a lazy data binding of the ListView and let the virtualizing presenter that's built into is manage the loading/display of the images.
Here's some docs on using a view-model. The viewmodel could coordinate the image load and provide the ListView with a binding source that would automatically get the application working.
A simpler alternative might be to start up a background thread and load the images into an ObservableCollection<>, bind that to the ListView and let the framework deal with the display.
I second what Greg D said, loading 200mb of images sounds like a recipe for problems.