Wpf Bing maps control very slow on touch devices - wpf

I am using Bing maps Wpf control.
When using on touch device (I am testing on touch screen monitor) it is very slow - Zooming, Panning, Rotating are extremely slow.
This is basically the same question as this on msdn forum, but there is no solution or workaround there.
It is obvious that this control is not optimized for touch, but I am wondering if anybody else has this problem and figured out some optimization?
Note: I have tested Windows 8 version of Bing maps control, but have to use Wpf version because it supports rotation (setting heading other than North).
Note: Number of pushpins is not important here, same problem is present with 0 pushpins.
Thanks for any help or useful suggestions!

A new version of the WPF control was actually just released within the past month. The update consisted of bug fixes and improved touch functionality. http://www.microsoft.com/en-us/download/details.aspx?id=27165
However, there are a couple of new bugs that have turned up since this release and our team has fixed them, but the new installers have not yet been released (will be soon).

Related

Zooming on Silverlight Toolkit charts?

I need to enable zooming on the Silverlight charts I use - at the moment this is Silverlight Toolkit. As far as I've understood the SL Toolkit charts don't support zooming, however I'm looking into implementing this functionality. So far I haven't managed to get far: applying ScaleTransforms to the Series elements doesn't work as expected.
Can anyone provide me with example code on implementing zooming in Silverlight Toolkit?
I've previously looked into implementing zooming on the Silverlight Toolkit charts, however failed because of (probably) the following reasons:
Silverlight Toolkit charts don't seem to have been designed to be able to extend for zooming. There are no hooks that you could easily attack some zooming logic to, if you want to create zooming on them, you have to go much deeer.
The simplest way of implementing zooming is using ScaleTransform and RenderTransform to elements. In case of Silverlight Toolkit you want to apply this to the series. However just calculating the correct ScaleTransform and OffsetTransform are difficult enough
When scaling, you don't want everything to scale. If you zoom in 4x on a line series with points on it, you don't want the line to be 4x thicker and the points to be 4x larger. This means that even if you did implement applying the ScaleTransforms and RenderTransforms correctly, all you would get is a magnifying glass, which is still far from ideal.
After a few hours I gave up on adding this kind of support to the SL toolkit charts and instead looked for other components that support zooming and have a decent API to deal with it. These are the components I've found (though I'm sure there's more):
Visiblox Charts free version: it has a nice API and implenting zooming takes only a few lines of XAML according to this blog post (also see a post on a comparison with SL toolkit charts). Full disclosure: I have been heavily involved in development of this library.
Infragistics xamWebChart also claim to have support for zoom in the premium version of their charts
Telerik RadCharts also seem to allow zooming based on this example - though it's not clear to me whether you'd have to implement this functionality yourself.
Summing it up, I think the easiest way for you to go it with a component that already has zooming implemented - from my experience it would take a lot of investment to add proper zooming + panning to Silverlight Toolkit charts.
You should take a look at user610173's blog post. Specifically, download the full example code here: http://slchartzoomandpan.codeplex.com/SourceControl/list/changesets Very helpful!
Adding to Gergely Orozy comment about Telerik:
You can easily add the Zoom functionality with the following XAML.
<charting:ChartArea.ZoomScrollSettingsX>
<charting:ZoomScrollSettings ScrollMode="ScrollAndZoom" MinZoomRange="0.005"/>
</charting:ChartArea.ZoomScrollSettingsX>
You can check out a demo by clicking here and the source code is also available on that same tab.

How to avoid visual artifacts when hosting WPF user controls within a WinForms MDI app?

When hosting WPF user controls within a WinForms MDI app there is a drawing issue when you have multiple forms that overlap each other that causes very distinct visual artifacts. These artifacts are mostly visible after dragging one child form over another one that also hosts WPF content or by allowing the edges of the child form to be clipped by the main MDI parent when dragging it around. After the drag and drop of the child form is completed the artifacts stay around generally but I've found that setting focus to a different application's window and then refocusing back on to my application window that it is redrawn and all is good again until the child forms are moved once again. Please see the image below which demonstrates the problem.
Those at Microsoft insist that the WinForms MDI is already a sufficient solution for MDI and doesn't need reinventing in WPF although I find it hard to believe they tried creating a WPF app this way because of the obvious shortcomings.
UPDATE: A few extra notes that I left out is that if I create these Forms without setting the MdiParent they are created as regular forms and this issue doesn't happen. This issue seems unique to the WinForms MDI scenario. Also I've currently running on Windows 7 Enterprise and I'm aware the results may be quite different on Windows XP but I haven't been able to test this.
UPDATE: I've found a few other related resources on this issue that I thought I should share.
elementHost repaint problem in MDI
application
elementHost repaint problem in MDI application on Tech Archive
It appears that another workaround is to revert to software rendering as opposed to taking advantage of hardware acceleration. This was the suggestion by Marco Zhou on the MSDN Forums.
public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
this.Loaded += delegate
{
var source = PresentationSource.FromVisual(this);
var hwndTarget = source.CompositionTarget as HwndTarget;
if (hwndTarget != null)
{
hwndTarget.RenderMode = RenderMode.SoftwareOnly;
}
};
}
}
I've tested this and this solution seems to work very well and so far is the only solution that I've found for solving this problem within a FoxPro interop scenario which is very similar to the WinForms one I posted about originally. For now I'm planning to use my original Refresh on the MDI Parent solution for my WinForms project but then for my other native interop applications such as when my WPF controls are hosted in Visual FoxPro I'll use this solution. That is unless of course if a more elegant solution is discovered for either of the cases.
Also it's important to note that from what I'm aware software rendering is the only option on XP systems and normally Visual FoxPro nore WinForms normally take advantage of the same type of hardware acceleration that native WPF apps do on Vista OS and up. So using this option may not be as bad as it sounds when you do have to deal with interop. Currently I'm not aware of any related side effects when using this solution but if there are any those would have to be taken into serious consideration.
Well, I may have found a solution although it feels like a bit of a hack. It appears that if you call the Refresh method on the MDI parent whenver a child MDI Form is moved that the noted artifacts go away. Visually things appear a bit jittery when dragging a window but it seems much more acceptable than the example I showed in my original post.
private void Form1_Move(object sender, EventArgs e)
{
this.ParentForm.Refresh();
System.Diagnostics.Debug.WriteLine(string.Format("Form Moved to: ({0},{1})", this.Left, this.Top));
}
I've tried many combinations in the same vein such as refreshing just the child window that was being moved by calling methods such as Update(), Invalidate(), Refresh() and also I've tried these same methods on the MDI parent as well as Dispatcher.Invoke(DispatcherPriority.Render, ...) and InvalidateVisual() on my hosted WPF control but none of those other methods worked accept for calling Refresh() specifically on the MDI parent.
I realize that this probably isn't the optimal solution since I'm forcing the whole main application window to refresh every time a child window moves a few pixels but as for right now it's the only reasonable solution that I found that works. If anybody else has any alternative solutions or any improvements upon this I will gladly accept your answer instead.
Check video drivers and try disabling hardware acceleration. Most artifacts are caused by bad drivers, failing video card, or insufficient time to complete the refresh.
First troubleshooting step: Update video drivers. Obvious, I know.
I had similar issue, checking my video card settings (NVidia Control Panel) showed global setting set very high causing a longer refresh interval which may be aborted if taking too long. Setting my settings back to defaults resolved most of the issue. But I also run hashing programs which use the GPU intensely so this is likely the cause of my remaing artifact issue which is very seldom now and mostly shows its ugly face in Visual Studio.
Another troubleshooting step I ran across is to disable hardware acceleration for WPF, this can be done in 'HKEY_CURRENT_USER/SOFTWARE/Microsoft/Avalon.Graphics', or maybe an application can do it BUT this is only for troubleshooting; never set these within an application because it will disable for ALL WPF applications. I do not have this registry setting nor did I add it so I am not sure of the success with it, but many say this resolved their issue. Also note some applications have this option available, try disabling it if available.
Another troubleshooting step is to make sure the video card is a proper tier level for rendering. Any card that supports DX9 or greater should be sufficient, but other factors are involved (as is my case) so just because it is on the list does not mean it is adequate for your purpose.
Finally, you can use the Visual Profiler (part of Windows SDK), and other tools, to help determine what is going on more precisely with WPF lacking performance in relation to graphics ability.
Rendering Tier level notes and WPF Performance information --> http://msdn.microsoft.com/en-us/library/vstudio/ms742196(v=vs.90).aspx
Hope this helps someone.
--Ryan Strassburg
Your usercontrol or window loaded event ;
this.WindowState = System.Windows.WindowState.Minimized;
this.WindowState = System.Windows.WindowState.Normal;
it may seem bad solution. no need to hit your head against the wall.
A Turkish proverb says: the best code is the code is running :)

What commercial WPF suite is better? Please suggest

Im working on a middle size project, using WPF. Need DataGrid, suitable for the client: fast, customizable, beautiful. Which component suite do you suggest from your practice?(for example Devexpress's, telerik's, Infragistics's and etc)
I have used Telerik data grid in the past and it seemed to have the least hastles for me compared to others I have had a look at.
However I can pretty much put my money on it that someone else would feel that Telerik's control wasn't great and that Infragistics was better etc. - so I suggest that you maybe download the trials and test them for your specific scenario.
"Fast, customizable, beautiful." - try Xceed's (I work there), there's a no-install XBAP demo. Also supports asynchronous data virtualization and smooth scrolling and other stuff no other datagrid does.
Xceed DataGrid for WPF main page
XBAP demos page
I've been evaluating Xceed for a few weeks now and while it is powerful it's dog slow when placed in a tab control switching between tabs. 30 seconds to open a tab on a large data set. The forum on their website seems to suggest this is a known problem without resolution. Shame as in other aspects it appears to do a good job.

WPF Architecture and Direct3D graphics acceleration

After reading the wikipedia article on WPF architecture, I am a bit confused with the benefits that WPF will offer me. (wikipedia is not a good research reference, but i found it useful). I have some questions
1) WPF uses d3d surfaces to render. However, the scenegraph is rendered into the d3d surface by the media integrated layer, which runs on the CPU. Is this true ?
2) I just found out by asking a question here that bitmaps dont use native resources. Does this mean that if i use alot of images, the MIL will copy each when rendering, rather than storing the bitmaps on the video card as a texture ?
3) The article mentions that WPF uses the painters algorithm which is back to front. Thats painfully slow. Is there any rational why WPF omits using Z-buffering and rendering front to back ? I am guessing its because the simplest way to handle transparency, but it seems weak.
The reason i ask is that i am thinking it wont be wise for me to put hundreds of buttons on a screen even though my colleagues are saying its directx accelerated. I dont quite believe that whole directx accelerated bit about WPF. I used to work on video games and my memory of writing d3d and opengl code tells me to be cautious.
For questions #1 and #3 you might want to check out this section of the SDK that discusses the Visual class and how it's rendering instructions are exchanged between the higher level framework and the media integration layer (MIL). It also discusses why the painters algorithm is used.
For #2, no that is most definitely not the case. The bitmap data will be moved to the hardware and cached there.
I tested that, I wrote two programs that show 1,000 buttons on screen, one in WinForms and one in WPF, both worked just fine.
I then pushed that up to 10,000 buttons, at that point the WPF app took a few seconds to start but run just fine, the WinForms app didn't start.
Win32 itself (and WinForms) isn't built for applications with hundreds of controls (believe me I wrote such an app), at some point it just stops working, WPF on the other hand, keeps working even if it slows down a bit at some point.
So, if you do need to put a lot of controls on screen WPF is your best bet (unless you want to roll your own UI framework - and you think you can do better than the entire MS perf team).
Also, WPF has many advantages other than graphics acceleration: richer graphics, drawing model that is easier to work with, animations, 3d and my personal favorite - amazing data-binding.
This will let you develop richer UIs faster - and I think that will make a much bigger difference than the painting algorithm used.
BTW, if you need to put hundreds of buttons on the screen this is likely to be a bad user experience and you may want to reconsider your UI design,

Is there a good iTunes coverflow-type control for WPF?

I am currently using Telerik's carousel control, but it is lacking many features and is buggy. Is there a good control out there that looks the the coverflow control in itunes?
WPF Cover Flow Tutorial
Source Code: Part 7, Download
Author's rebuttal to claim of memory leak (it doesn't): Part 8
In Action: Videos
Contains a detailed walkthrough for building a coverflow control, including features such as reflection. I compiled and tried it out and pointed it to a directory containing hundreds of smallish images (you'll need to edit TestWindow.xaml.cs to point to a directory containing jpg's) and I was impressed with the performance and smoothness of the animation.
I noticed that using very large images degrades the performance though, so I'd recommend using images that are just the size needed for display. For example, when pointed to my desktop background images directory, there was nearly a one-second delay after pressing the arrow key and the item going through the transition (although the animation itself was still fluid, it took a moment to begin).
This is the best one that I found, for what I was looking for - namely, non-commercial, reflections, and smooth animation. I did look at the other ones currently mentioned in the other answers though, here are some comments on them (in no particular order):
FluidKit's ElementFlow
Open source, I used the latest source code, but did not try out any patches
Animation was smooth
Transition didn't feel very refined, the pictures clip each other in an odd way
Didn't seem geared for showing a handful of element's on the screen at once, it tries to show everything, and from some of the discussion comments, apparently isn't virtualized
After adding some images to the demo through the provided button, a large portion of them couldn't seem to get selected
Doesn't have reflections
Mindscape CoverFlow
Commercial
Animation was smooth
Doesn't "popup" selected item, feels very 2D
Has reflections
DevExpress Carousel
Commercial
No online demo and I didn't try to obtain the trial, looks polished though
Telerik Carousel
Commercial
Animation was smooth
The transition wasn't as pleasing to me, the new picture passed through the old one
Doesn't have reflections
Xceed Cardflow 3D
Commercial (professional edition only)
Animation was smooth, if you went quickly it would show blank cards speeding by and then fade in the actual data on the cards when you slowed down
Supports flipping the selected item, like in iTunes
Has reflections
ElementFlow control is inside the codeplex project called FluidKit - can be downloaded from here
For more details about the control - ElementFlow control at Pavan's blog
Mindscape now provide a commercial WPF Coverflow control as part of their WPF Elements control pack that might be useful also.
http://www.telerik.com/products/wpf/carousel.aspx
http://www.devexpress.com/Products/NET/Controls/WPF/Carousel/dependency_properties.xml
Both of these are FAR more versatile than your average cover flow clone (though they can easily just do that too if you want). I'd recommend Telerik well above DevExpress as WPF is still a relatively immature technology and DevExpress are very poor at keeping up with the tech game (they only JUST released a VS2010-supporting version of their DXperience suite despite promising it "just around the corner" since the start of January, while Telerik, ComponentOne etc all keep up with current tech. Not good enough for enterprise).

Resources