We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy.
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Performance Issues in diagram control for silverlight

Thread ID:

Created:

Updated:

Platform:

Replies:

103039 Mar 26,2012 12:53 PM UTC Aug 20,2012 02:02 PM UTC Silverlight 11
loading
Tags: Diagram
Andreas Kostian
Asked On March 26, 2012 12:53 PM UTC

Hello,

we use the diagram control inside a TabControl, which itself is part of TabControlAdv.

The TabControlAdv consists of 8 Tabs; in each TabPage there is another TabControl (with the tabitems aligned left vertically).

Each time the user chooses a new tab page a diagram control is built showing information about the tab item chosen.

We didn't built one diagram control for each tab page, but only one, which is created new on demand.

Now it seems, that the application is slowing down the longer it runs and the more often the user switches between the tab pages. Could this be because of recreating the diagram control new after every switch?

If so, is there a better way to use the diagram control? As I could see it doesn't have Dispose-Method. Any other way to clean it up before recreating it?

Andreas


Ramya Thirugnanam [Syncfusion]
Replied On March 30, 2012 03:36 AM UTC

Hi Andreas,
With regards to Performance Issues in diagram control for Silverlight, we are analyzing on the reported issue .we will get back to you with the status of this issue on April 3rd 2012.
Please let us know if you have any concerns,
Regards,
Ramya



Andreas Kostian
Replied On April 4, 2012 01:23 PM UTC

Hi Ramya,

is there any update in the meantime?

I found out, that it could be the TabControlAdv which causes the performance problem.

Should I try to create an example to reproduce the performance problem?

Regards,

Andreas


Andreas Kostian
Replied On April 5, 2012 08:58 AM UTC

Hi Ramya,

I created an example to demonstrate the performance problem. It's attached.

After starting the app and changing the selected TabItemAdv on the tab (5 - 10 times is enough), the application slows down significantly. Beside the SelectedItemChanged event I also catch the LeftMouseButtonDown on the TabItems and figured out, that it can take more than two seconds between ButtonDown and SelectedItemChanged event.

It seems to me also, that a diagram control, which is not needed anymore (meaning it is not referenced anymore) takes some time to get cleaned up.

Furthermore in this example I have the problem, that the content of the diagram (three nodes connected) is not shown after creating. I have to move the scroll bar on the right a bit to make the content visible.
How can I make the content shown directly after adding the nodes?
And in this case I don't need a scrollbar for the diagram view, because it is quite small. How can I prevent the scroll bar being shown in this case?

Mabye it's a strange way of using the diagram control. But in our software each selection of a TabItem on the top (x-order) and a selection of a TabItem on the left (y-order) leads to a different diagram.

Regards,

Andreas



PerformanceTest_d2b206ff.zip

Ramya Thirugnanam [Syncfusion]
Replied On April 10, 2012 03:58 PM UTC

Hi Andreas,
Issue with TabcontrolAdv:
With regards Performance Issues could be the TabControlAdv which causes the performance problem, we are analyzed the provided sample. The problem is not due to TabcontrolAdv. We have provided the profiler result to represent this. Please refer to the attachment.
Sample changes:
Performance Issues could be the TabControlAdv and that the content of the diagram (three nodes connected) is not visible are sample level problem, we have modified the sample in such a way to improve the performance. Please refer to the sample from the attachment.
Please let us if you have any concerns,
Regards,
Ramya




Performanceissue_6394683b.zip

Andreas Kostian
Replied On April 11, 2012 07:52 AM UTC

Hi Ramya,

thanks for checking my example.

As I could see, you removed the LayoutType and Orientation from the Model to improve the performance.

And you removed the scroll viewer, which I used as a container for the left TabCtrl. This is causing a problem, because sometimes we have more TabItems on the left side than the application could display.
So we use a scroll view to make it possible for the user to scroll through the tabitems TopDown.

In the again modified example attached I use the scrollview again and each time I add 70 TabItems to the TabControl on the left side.
Now I have the problem again, that beside the scrollbar of the ScrollView I have a second one of the DiagramControl, which is not really needed. Is there a way to remove it?

After starting the application now the first diagram is shown properly, but after selecting another tab the new diagram again is only shown after moving the scroll bar a bit. Although it is the same method building the diagram.

And still I have a significant delay between the "MouseButtonDown"- and the "TabItemChanged"-Event. I don't do anything after the "MouseButtonDown", only tracing it. But after selecting different tabs for 5-10 times, the delay between "MouseButtonDown" and "TabItemChanged" is more than 2 seconds on my machine?
Furthermore: It seems to me, that selecting a tab with the tabpopupmenu on the very right side is even slower.

So my questions:

1. How can I remove the second Scrollbar, if I have to use the ScrollView to make the left TabItems scrollable?

2. How could I assure, that the diagram is shown properly after switching to a new TabItem?

3. Do you have any explanation for the delay between "MouseButtonDown" and "TabItemChanged"?

Regards,

Andreas





PerformanceTest-remodified_96f26f5e.zip

Andreas Kostian
Replied On April 11, 2012 02:53 PM UTC

Hi Ramya,

as an update I tried to use a standard windows Tabcontrol instead of a TabcontrolAdv. Still the same perfomance problem.

It seems to me, that after I changed the TabItem, the diagram control has to get invisible and maybe disposed. Possibly this is causing the problem?

Regards,

Andreas


Andreas Kostian
Replied On April 17, 2012 11:45 AM UTC

Hi Ramya,

I was able to speed up the performance by using always only one diagram control, which I always reset and populate again, if another tab was selected. This is significantly faster than always creating a new diagram control. It seems to be, that cleaning up a unused control takes a lot of time.

What I still need to know is, how I could prevent the second (inner) scrollbar to be shown, if I use a scrollview to make all TabItems accessible?

Any tips for me on this issued?

Regards,

Andreas




Jegan R [Syncfusion]
Replied On April 19, 2012 12:31 PM UTC

Hi Andreas,

Sorry for the delay in getting back to you.

Currently hosting Diagram in a ScrollViewer will have some unexpected result. It is by design that Diagram tries to utilize all the available space given it to. When Diagram is hosted inside a ScrollViewer, it gives infinite size to Diagram, which results in undesired effect. When outer ScrollViewer is removed we are able to see everything is working fine.

However we will consider this as issue and fix it. For having the better follow up, please touch with us through Direct -Trac.

Please let us know if you need any further details.

Regards,
Jegan


Andreas Kostian
Replied On April 19, 2012 01:09 PM UTC

Hi Jegan,

thanks for explaining the behavior of the diagram control.

Well, in my example the diagram control is hosted inside a tabitem, which itself is part of a tabcontrol, which is hosted inside a scrollviewer.
Doesn't make this any difference?

Do you have suggestion how we could use a large nummer of tabitems (like shown in my last update) without using a scroll viewer?

Best regards,

Andreas


Jegan R [Syncfusion]
Replied On April 25, 2012 03:38 AM UTC

Hi Andreas,

Though there are TabControl and TabItem in between ScrollViewer and Diagram in the visual tree, the alignment is usually passed through the visual tree. Which does not make much difference.

As already said this a control issue and we will fix it our future releases. For having the better follow up, please touch with us through Direct-Trac.

Current workaround for you requirement is to specify Width and Height property to DiagramControl, as shown in the following code snippet.

Code Snippet: (While hosting diagram inside ScrollViewer)

DiagramControl dc = new DiagramControl();

DiagramView view = new DiagramView();

// When size of the DiagramPage changes, set the same to DiagramControl
view.Page.SizeChanged += (s, e) =>
{
dc.Width = e.NewSize.Width;
dc.Height = e.NewSize.Height;
};

Please let us know if you have any clarification.

Regards,
Jegan



Andreas Kostian
Replied On August 20, 2012 02:02 PM UTC

Hi!

I have to come back to this issue again:

I use your code snippet to get rid of the two parallel vertical scroll bars:

view.Page.SizeChanged += (s, e) =>
{
    dc.Width = e.NewSize.Width;
    dc.Height = e.NewSize.Height;
};

This works fine as long the content of the diagram doesn't get to wide. But if it does, I have no horizontal scroll bar to scroll left or right in my diagram. This means I have to chance to see everything of the diagram.

As I found out there is a read only property in diagramview called "GetHorizontalScrollBarVisibility", which is by default Auto.

Is there a way to always enable a horizontal scroll bar in a diagram view, so I can scroll throught the whole content of it?

Kind regards,

Andreas


CONFIRMATION

This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon

;