C# Monotouch/Xamarin - Reduce Launch Screen Display Time - c#

Summary
I currently use the standard method for increasing the screen size width to iPhone 5 (by adding a launch image that is the same size as the iPhone 5 screen).
This launch image is added via the info.PList.
It takes a very very long time for this image to fade into the rootViewController.
Questions
What determines the length of time that the launch screen is displayed for?
Can I control/decrease this timeframe?
Can I control the launch screen time programmatically, despite having not added the launch screen image programmatically?
Many thanks.

That's the time while the OS (iOS in this case) is preparing your application to start.
No. You can not. (You can not do anything but specifying the image file in your configuration).
The launch time is the time when OS is preparing your app. The launch time is the time when OS is preparing your app + the time while ...Launching methods finish calls. And right your code gets an access, it (the launching image) is no more shown. However, obviously, you can just show the same image as your default image in your UI and continue doing some custom preparations. But me personally would consider that like 'wasting a chance to already start "entertaining" of users'.
P.S. This question is actually related to Xamarin pretty not much. Except, that considering Xamarin binaries size can just reduce the app launching time. But generally, many similar questions are widely available through "native iOS"/objective-c questions (even here on stackoverflow).
updated:
Actually, thanks Kirk for the correction on the details about FinishedLaunching. But I would really not recommend to play (freeze) much with that method as if your app won't respond in certain time, it will be terminated. Especially, as the freezing will be 100% just wasting time for users.

Related

Part of my GUI is slow

I ran into a problem with my GUI.
My GUI has multiple parts in it.
The first one is for an image (from 500x500 to 3000x3000 and it has to update up to 4 times each seconds)
The second one is the main menu
The third one has buttons with options regarding the image. I am not showing all of them at once, I scroll through several menus and i render only the ones who are visible. (An example for the otpions is the pixelsize of the image)
I display the image inside a Viewbox which is 800x800px big. I stretch the image inside of the box with Stretch="{Binding Path=StretchMode}"
The Image I get is some kind of stream. I get multiple Images each second.
Now when I display an image, the first GUI part works fine (regardless of the image size) but the others sometimes have a heavy framedrop. I will give some examples:
Example 1:
The image is 500x500 pixel big. I can work without a framedrop and the whole gui updates correctly.
Example 2:
The image is 1500x1500 pixel big. I can work without a Framedrop and the whole gui updates correctly.
Example 3:
The image is 2500x2500 pixel big. The Image updates fast but the rest of the GUI have framedrop from 60 fps to fps and sometimes even to 1 fps.
My thoughts about this problem were:
Hardware is at its limit. But a look on the Taskmanager and CPU/RAM analysis with Visual Studios says it is allright.
It is too much to render for the GUI because 3000x3000 is big and 4 times each seconds is not slow either. After a test with loaded (I loaded them from a hdd-drive) 3000x3000 images (Same Datatype) it worked fast and without problems.
Too much changes of the GUI at once. I tried the Software with only 5 updates. Still the same problem.
Microsoft Prism event not occuring. This wasn't it either because it comes inside the Controller and is Raising the changes if there is a change. (I have a logger which writes logfiles and it is raising the Change event more than the GUI is really changing)
Usage of a different datatype. Possible but i tried out several. (BitmapSource, BitmapImage and WriteableBitmap)
Outsourcing some rendering options in another thread. Still no change.
I hope you can give me some ideas why the GUI has this behaviour.
If you need code, please tell me.
I am not using a VM.
The problem occurs on Windows 7 64 bit and Windows 8.1 64 bit (not testet on Windows 10)
My hardware differs. The problem appears on my laptop (Intel i7-4702MQ #2.2 Ghz, 8 gb ddr ram, intel board graphics) and on workpc's with different specs (the highest are: Intel Xeon with 3.5 Ghz, 128 GB DDR4 Ram and a Titan X and a 4k Monitor)
EDIT: Apologies, stack doesn't have my score high enough to comment, so comment-ish content here instead.
EDIT1: Process explorer (from Sysinternals) should be used perhaps as a low-hanging fruit to see what (if any) video resources have a high consumption. there is a tab/area in process explorer for looking at graphic resources. In process explorer you can do a 'select columns' and add GPU resources for easy viewing. Might be a good angle to try.
I would venture a guess at this point that we are dealing with a
An ETW trace with DPC data might be helpful. Also you don't mention if you are in a VM or not, a VM would make taskmanager reflect inaccurate resource consumption on CPU.
An example of how to collect such a trace is here: https://blogs.technet.microsoft.com/jeff_stokes/2012/09/18/how-to-collect-a-trace-for-audio-or-video-problems-in-windows-7/
In any event, I suspect you are looking at kernel drivers or IPC/DPC issues rather than just raw CPU consumption here. More data needs to be provided I think. (hardware specs, OS used, VM/not).

Accessing each video frame from a webcam in Windows Form C# application

, Hi, everyone. I'm currently experiencing some problems with an image capture application I need to complete in C#.
I have a Windows Form C# program that uses the DirectShow .NET library to obtain a constant flow of still images from a webcam at about 20+ frames per second. Each image is loaded into a System.Drawing.Bitmap object and processed with some filters and logic. The result is presented to the user in a picture box as the modified capture from the webcam at the same frame rate of capture or saved to disk in JPEG format.
It all works well except for the capture itself. After capturing still images constantly for a random period of time (anywhere from minutes to hours), I start getting exceptions from DirectShow .NET that the still capture timed out, or simply crashes and the whole program stops working.
I have tried to dispose of the DirectShow .NET resources and re-acquiring them, but in some instances, the program hangs waiting for either the disposal to complete or for the re-acquisition to happen.
I don't know if I'm doing it right by using the still capture, or if there is another way to access each frame from the camera with DirectShow .NET or any other technology to do the described processing that will not cause any problems after extended periods of uninterrupted work.
I do not need to show the processed video frames to the user all the time, so, I cannot have a preview window showing all the time. When the user is not monitoring, the program saves the frames to disk in JPEG format.
Any suggestions on what could be the problem, or if I should switch to another technology for the capture (if so, suggestions and information are welcome)?

Screenshot capture from monitors with different resolutions in WPF

I want to take a screenshot of the user's currently active window (and run OCR on top of it at a later stage). This (e.g. described here) works fine as long as the developer works on standard monitors with the same resolution.
The problem is, that WPF uses device-independent units and the native API functions require pixels. I found many resources how to fix this for my own WPF application, most prominantly here and here. However, I found no way to do this dependent on what monitor the window is currently shown. For example, if the developer has a laptop with a QHD dipslay and uses a secondary monitor with a normal HD resolution. I found a C++ solution on MSDN, but not in C#.
Does anyone have experience with this or any suggestions?
Thanks.

CPU Throttling Issues with WPF

I am working on an application in WPF using Vlc.DotNet. I was having an issue with the video playing back with a terrible frame rate on my laptop.
After some research I identified that the issue is related to the CPU throttling down. If the laptop power profile is in BatterySaver mode it has the issue. If I switch it to performance, everything works fine. It seems to me like in BatterySaver mode it allows the processor to throttle down, and for some reason doesn't throttle back up correctly when the application needs it to. Is there anyway I can fix this issue?
I tried setting the priority with the code below and it didn't seem to make a difference.
System.Diagnostics.Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;
Vlc.DotNet updates and ImageSource with the next rendered image. I have this source bound to an Image on the GUI that displays it. I used the WPF Performance Kit and can see what is happening, but not why. As soon as it starts playing, AKA updating the image on the GUI at 30fps, the frame rate of the entire application drops down to around 5fps.
Have you tried switching to software rendering to avoid the bottleneck of CPU power downs? I know WPF uses a separate thread for rendering and I'm not sure if you can even access it from Process.Threads. What I've done in the past is attach to the power mode changed event and switched the mode dynamically like this so power mode changes don't switch to hardware rendering. Not sure if this will work as I don't what your specific bottleneck is, but hopefully this points you in a good direction.

Playing videos in C# application via Windows Media Player. Is there a stable, decently performing solution?

I've written a WPF application (in Visual C# 2010 Express) that has 2 windows. The 1st has a various buttons, the other displays video using the MediaElement control. When a button is pressed, a video associated with it is played or stopped if it's already playing.
On my development machine (Windows 7, good graphics card, lots of memory etc), this runs fine. The only problem I've encountered is that when attached to the debugger it is very unstable but when run normally these issues go away.
Unfortunately when run on a much less powerful XP machine the videos run at 1-2fps. This is despite the fact that the videos run fine in Windows Media Player.
There seem to quite a lot of reports of poor performance for the MediaElement control (not to mention inconsistencies in what it can play) so I decided to look at some alternatives.
I tried a free library call WPF MediaKit (http://wpfmediakit.codeplex.com) that I thought might have some effect, however while I've got it to work on an XP machine, it resolutely refuses to display videos on my development machine despite using exactly the same code. I'm still hoping I can this to work but I'm not confident it will help given it's still using the MediaElement control behind the scenes.
I then tried using wmp.dll COM control (Windows forms rather than WPF) and even with the simplest app (new Windows Form project, WMP control added to form, and 1 line of code to set the URL on load) I get odd behaviour. With the debugger attached, it works across multiple monitors, but sometimes when it starts playing, it just repeatedly stutters over the 1st few frames and the only way to break it out of this seems to be to move it to the other monitor. If I'm not using the debugger, I don't seem to get the stutter issue but the video is only displayed on the main monitor, as soon as I move the window to the secondary monitor, it goes black.
So my question is has anyone experienced anything like the above and/or have a decent solution to it? It would be especially nice to find something that works consistently with and without the debugger attached!
Have you tried this library?
http://directshownet.sourceforge.net/about.html
There's also this .NET interface to VideoLAN media player, but that introduces a dependency to VLC:
http://wiki.videolan.org/.Net_Interface_to_VLC
WPF MediaKit does not use MediaElement behind the scenes, but instead uses the D3DImage interop class to provide high performance video to WPF.
WPF in XP has always been a hit-or-miss in terms of performance. You might want to take a look at the rendering tier to ensure WPF is fully hardware accelerating. Also make sure you have the newest video drivers available and that the GPU is capable.
-Jer

Categories