We Keep Coding

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).

C# Monotouch/Xamarin - Reduce Launch Screen Display Time

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.

Poor StackPanel performance with WPF

I have an application which runs fullscreen on a high resolution display (1920x1080).
About 25% of the screen is a StackPanel that scrolls images across the screen.
(the X position is animated with double animation)
The scroll is very laggy and jumpy, and with visible tearing.
This is running on a brand new high-end gaming laptop, running Win7 64bit.
I don't understand why the performance is so poor. Am I doing something wrong? Does this kind of animation run on the CPU or GPU? Is there a smarter way to scroll images across the screen?

WPF can be hardware-accelerated, but only on newer video card drivers. Some of the onboard, out of box drivers, will default back to software rendering, which can feel really slow and clunky. As for the tearing, that's a normal video card setting, called V-Sync. I would try updating the video card drivers to a proprietary driver (nVidia, AMD, etc.), and enabling vertical sync on the card.
You can check to see if it falls into software, or hardware rendering using the methods explained here.
If that doesn't resolve the issue, the only other possibility I can think of is your animation/rendering is not synced to the GUI.
See this msdn article for more details.

A trick that I've seen that can get around this issue is to place a 3D object on your page, view it side on and rotate it e.g. for 4 images have a cube with an image set to each side.
Yes the rotation still requires GPU and processor time but it is taken care of internally by the WPF animation and so doesn't require interaction with code behind once set rolling.

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

WPF video tearing on Windows XP

I've created a WPF application using C# that renders about 50 3D elements and animates the camera in order to move around the scene.
While it all works, I've noticed as the camera moves, ugly video tearing occurs.
I'm well aware of the standard cause of tearing, ie the application is updating frames at a different rate from the monitor/adapter vertical sync.
I've also read that the default screen update rate in WPF is 60 frames per second and that on XP WPF updates without regard to the montior v-sync.
For certain scenes the tearing is less noticeable, but often it is distracting enough to be a real problem.
I'm really hoping there is a resolution, after all Windows Forms has had double buffering for years. Moving to WPF is actally a backward step for many types of application if there is no resolution.
So, on Windows XP, how can I configure WPF to remove tearing?
I'm looking for more helpful answers then "move to Vista". This is simply out of the question for many of the future users of this application.

No answers yet, surely with the number of WPF developers out there someone else has seen this problem?
In the meantime I've investigated/read some more and have come across the Timeline.DesiredFrameRate property.
With my display running at 50hz vertical refresh I tried setting this to 50 FPS in the hope this would brings things in sync. Unfortunately this had no effect on the tearing.
However, I did have to apply it to a single specific animation I created (in code) using BeginAnimation(). I'm not sure how this would affect a "global" framerate at all.
Instead, I would have expected to need to do this at a more global level, say on the viewport, however I couldn't find DesiredFramerate property on the viewport object.
Another area to look at could be the RenderCapability.Tier but I haven't had the time to look in detail yet.
[Update]
No solution but a useful tip. To set the DesiredFramerate globally (ie for all animations in the viewport) you can override the PropertyMetadata for the
Timeline.DesiredFrameRateProperty dependency property:
// Set the global desired framerate to 50 frames per second
Startup += delegate(object sender, StartupEventArgs e)
{
Timeline.DesiredFrameRateProperty.OverrideMetadata(typeof(Timeline),
new PropertyMetadata(50));
};
It's best to place this in the constructor of the standard WPF Application class.
Unfortunately this didn't solve my problem because even setting it to FPS, it must not be synced accurately enough with monitor v-sync.
It is handy to know about though, particularly if you have slow moving animations and want to save CPU usage by setting the FPS much lower then the default 60fps.
[Update]
Setting the DesireFrameRate to some very high value such as 100+ seems to reduce but not remove the flicker. One big drawback however is that the CPU (on my 4 yo PC) goes to 35%.