#10170 Improve performance of DrawClippedline
↧
Source code checked in, #8e2b2285bbd1
↧
Commented Unassigned: incorrect and missing points rendered from LineSeries [10170]
In RederingExtensions the:
* First point is always added regardless of whether it's inside the clipping region or not
* First point of every clipped line segment is skipped
In addition, there are a couple of performance issues:
* Boxing is occurring on every ScreenPoint
* New lists are constantly being created instead of just clearing the old list
I think I fixed the issues (see attached). I also added another performance improvement of injecting the intermediate output buffer for ScreenPoints. This prevents the buffer from constantly copying itself and stressing 3rd generation garbage collection. This may be able to be omitted in lieu of presizing the buffer. However, I chose the less clean interface to reduce the risk of garbage collection killing our app. This is just for our stuff, since we're rendering millions of points using MVVM. The garbage collector was actually killing our application performance due to Oxyplot (we run an instrument and it was shutting our data collection down). _BTW, do I need to copy your copyright into the attached file, or is it OK to just simply include the license file in our distribution & installer?_
I actually have permission to give you the full source that allows us to render millions of points using MVVM if you desire. You could incorporate everything but data appendage into your project without messing things up too much. There are a few things that you could do cleaner by having it in your source. I have some code for data appendage also, which doesn't require any series to be redrawn, but has some extra state to manage. Just let me know if you would like any of this.
Comments: Thanks for the input! This improved the performance of the DrawClippedLine method by 50%. But I did not see much improvement when changing from IList<T> to List<T>. Please have a look at the latest changes, I also inlined the Cohen-Sutherland outcode calculations.
* First point is always added regardless of whether it's inside the clipping region or not
* First point of every clipped line segment is skipped
In addition, there are a couple of performance issues:
* Boxing is occurring on every ScreenPoint
* New lists are constantly being created instead of just clearing the old list
I think I fixed the issues (see attached). I also added another performance improvement of injecting the intermediate output buffer for ScreenPoints. This prevents the buffer from constantly copying itself and stressing 3rd generation garbage collection. This may be able to be omitted in lieu of presizing the buffer. However, I chose the less clean interface to reduce the risk of garbage collection killing our app. This is just for our stuff, since we're rendering millions of points using MVVM. The garbage collector was actually killing our application performance due to Oxyplot (we run an instrument and it was shutting our data collection down). _BTW, do I need to copy your copyright into the attached file, or is it OK to just simply include the license file in our distribution & installer?_
I actually have permission to give you the full source that allows us to render millions of points using MVVM if you desire. You could incorporate everything but data appendage into your project without messing things up too much. There are a few things that you could do cleaner by having it in your source. I have some code for data appendage also, which doesn't require any series to be redrawn, but has some extra state to manage. Just let me know if you would like any of this.
Comments: Thanks for the input! This improved the performance of the DrawClippedLine method by 50%. But I did not see much improvement when changing from IList<T> to List<T>. Please have a look at the latest changes, I also inlined the Cohen-Sutherland outcode calculations.
↧
↧
Commented Unassigned: incorrect and missing points rendered from LineSeries [10170]
In RederingExtensions the:
* First point is always added regardless of whether it's inside the clipping region or not
* First point of every clipped line segment is skipped
In addition, there are a couple of performance issues:
* Boxing is occurring on every ScreenPoint
* New lists are constantly being created instead of just clearing the old list
I think I fixed the issues (see attached). I also added another performance improvement of injecting the intermediate output buffer for ScreenPoints. This prevents the buffer from constantly copying itself and stressing 3rd generation garbage collection. This may be able to be omitted in lieu of presizing the buffer. However, I chose the less clean interface to reduce the risk of garbage collection killing our app. This is just for our stuff, since we're rendering millions of points using MVVM. The garbage collector was actually killing our application performance due to Oxyplot (we run an instrument and it was shutting our data collection down). _BTW, do I need to copy your copyright into the attached file, or is it OK to just simply include the license file in our distribution & installer?_
I actually have permission to give you the full source that allows us to render millions of points using MVVM if you desire. You could incorporate everything but data appendage into your project without messing things up too much. There are a few things that you could do cleaner by having it in your source. I have some code for data appendage also, which doesn't require any series to be redrawn, but has some extra state to manage. Just let me know if you would like any of this.
Comments: I think changing to array and making the fields of the `ScreenPoint` struct public could make some difference. See https://gist.github.com/oeb/9949912
* First point is always added regardless of whether it's inside the clipping region or not
* First point of every clipped line segment is skipped
In addition, there are a couple of performance issues:
* Boxing is occurring on every ScreenPoint
* New lists are constantly being created instead of just clearing the old list
I think I fixed the issues (see attached). I also added another performance improvement of injecting the intermediate output buffer for ScreenPoints. This prevents the buffer from constantly copying itself and stressing 3rd generation garbage collection. This may be able to be omitted in lieu of presizing the buffer. However, I chose the less clean interface to reduce the risk of garbage collection killing our app. This is just for our stuff, since we're rendering millions of points using MVVM. The garbage collector was actually killing our application performance due to Oxyplot (we run an instrument and it was shutting our data collection down). _BTW, do I need to copy your copyright into the attached file, or is it OK to just simply include the license file in our distribution & installer?_
I actually have permission to give you the full source that allows us to render millions of points using MVVM if you desire. You could incorporate everything but data appendage into your project without messing things up too much. There are a few things that you could do cleaner by having it in your source. I have some code for data appendage also, which doesn't require any series to be redrawn, but has some extra state to manage. Just let me know if you would like any of this.
Comments: I think changing to array and making the fields of the `ScreenPoint` struct public could make some difference. See https://gist.github.com/oeb/9949912
↧
Source code checked in, #0726d9ef4887
#10170 Improve performance of CohenSutherlandClipping
↧
Source code checked in, #55c0b85f53ff
Wpf: fix context menu (discussions/540989)
↧
↧
New Post: Context menu broken in the latest Nuget package?
should be fixed. see new example for Wpf.
↧
Commented Unassigned: incorrect and missing points rendered from LineSeries [10170]
In RederingExtensions the:
* First point is always added regardless of whether it's inside the clipping region or not
* First point of every clipped line segment is skipped
In addition, there are a couple of performance issues:
* Boxing is occurring on every ScreenPoint
* New lists are constantly being created instead of just clearing the old list
I think I fixed the issues (see attached). I also added another performance improvement of injecting the intermediate output buffer for ScreenPoints. This prevents the buffer from constantly copying itself and stressing 3rd generation garbage collection. This may be able to be omitted in lieu of presizing the buffer. However, I chose the less clean interface to reduce the risk of garbage collection killing our app. This is just for our stuff, since we're rendering millions of points using MVVM. The garbage collector was actually killing our application performance due to Oxyplot (we run an instrument and it was shutting our data collection down). _BTW, do I need to copy your copyright into the attached file, or is it OK to just simply include the license file in our distribution & installer?_
I actually have permission to give you the full source that allows us to render millions of points using MVVM if you desire. You could incorporate everything but data appendage into your project without messing things up too much. There are a few things that you could do cleaner by having it in your source. I have some code for data appendage also, which doesn't require any series to be redrawn, but has some extra state to manage. Just let me know if you would like any of this.
Comments: Things to consider: * The JIT for x64 might still suck since ryu-jit isn't part of .net yet. However, that's largely irrelevant here * I think you are, but please make sure you have your debugger detached while doing performance tests * The order of your tests matter a TON. I moved array before list and the relative performance of list went up. I also moved array reuse point before array new point and reuse point got slower. * The JIT may optimize out trivial property gets (as long as the property is not virtual). Also, I think there is a bug. When you write to a struct, your just setting the value you retrieved on your stack. The value doesn't stick inside the array - it's just a local change of the retrieved copy. Therefore, I think your array public fields results may not be valid.
* First point is always added regardless of whether it's inside the clipping region or not
* First point of every clipped line segment is skipped
In addition, there are a couple of performance issues:
* Boxing is occurring on every ScreenPoint
* New lists are constantly being created instead of just clearing the old list
I think I fixed the issues (see attached). I also added another performance improvement of injecting the intermediate output buffer for ScreenPoints. This prevents the buffer from constantly copying itself and stressing 3rd generation garbage collection. This may be able to be omitted in lieu of presizing the buffer. However, I chose the less clean interface to reduce the risk of garbage collection killing our app. This is just for our stuff, since we're rendering millions of points using MVVM. The garbage collector was actually killing our application performance due to Oxyplot (we run an instrument and it was shutting our data collection down). _BTW, do I need to copy your copyright into the attached file, or is it OK to just simply include the license file in our distribution & installer?_
I actually have permission to give you the full source that allows us to render millions of points using MVVM if you desire. You could incorporate everything but data appendage into your project without messing things up too much. There are a few things that you could do cleaner by having it in your source. I have some code for data appendage also, which doesn't require any series to be redrawn, but has some extra state to manage. Just let me know if you would like any of this.
Comments: Things to consider: * The JIT for x64 might still suck since ryu-jit isn't part of .net yet. However, that's largely irrelevant here * I think you are, but please make sure you have your debugger detached while doing performance tests * The order of your tests matter a TON. I moved array before list and the relative performance of list went up. I also moved array reuse point before array new point and reuse point got slower. * The JIT may optimize out trivial property gets (as long as the property is not virtual). Also, I think there is a bug. When you write to a struct, your just setting the value you retrieved on your stack. The value doesn't stick inside the array - it's just a local change of the retrieved copy. Therefore, I think your array public fields results may not be valid.
↧
New Post: Context menu broken in the latest Nuget package?
sorry, I forgot to add some files. Will fix this tomorrow.
↧
New Post: Context menu broken in the latest Nuget package?
Ok thanks!
↧
↧
New Post: Tracker Position in Winforms
Here's an example
Tracker Winforms Example
On further testing, it seems to be in relation to where you place the plot control relative to other controls. If other controls are placed to the left of the plot, the tracker seems to be still working of the form borders, not where the plot is.
However if you place the plot inside a container, like a group box, it seems to work again.
Regards
Tracker Winforms Example
On further testing, it seems to be in relation to where you place the plot control relative to other controls. If other controls are placed to the left of the plot, the tracker seems to be still working of the form borders, not where the plot is.
However if you place the plot inside a container, like a group box, it seems to work again.
Regards
↧
Source code checked in, #26b5ec82d36d
Add WPF ContextMenuDemo
↧
Source code checked in, #5ec0fdea17aa
Breaking changes:
change Points property of DataPointSeries,
change Points2 property of AreaSeries,
change Points property of ScatterSeries.
Remove IDataPoint, change point validation checks (performance bottleneck).
↧
Edited Unassigned: iOS invalidate plot control when changing orientation [10143]
when changing between portrait and landscape orientation, the plot control should be invalidated
↧
↧
Commented Unassigned: iOS invalidate plot control when changing orientation [10143]
when changing between portrait and landscape orientation, the plot control should be invalidated
Comments: I see this can be handled by overriding the DidRotate method in the controller. But it would be great if this could be handled by the UIView custom control. Is it possible?
Comments: I see this can be handled by overriding the DidRotate method in the controller. But it would be great if this could be handled by the UIView custom control. Is it possible?
↧
New Post: Scatter Plot with 3 Axis, One a LinearColorAxis
Hi,
i am wanting to create a plot which has three axes: 1. along the bottom of one scale (LinearAxis); 2. along the left side (LinearAxis) of another scale; and 3. along the right side (LinearColorAxis) as another scale.
I am able to get the first two and then by adding a ScatterSeries with x,y DataPoints display data. However, I am wanting to color the points based on some other value z using the color scheme of the LinearColorAxis.
Can someone help me with a simple example of this?
Thanks
i am wanting to create a plot which has three axes: 1. along the bottom of one scale (LinearAxis); 2. along the left side (LinearAxis) of another scale; and 3. along the right side (LinearColorAxis) as another scale.
I am able to get the first two and then by adding a ScatterSeries with x,y DataPoints display data. However, I am wanting to color the points based on some other value z using the color scheme of the LinearColorAxis.
Can someone help me with a simple example of this?
Thanks
↧
Source code checked in, #6de063aa2fe0
Disable CS 1718 warning (NaN test by equal expression)
↧
Source code checked in, #ee749d53190f
#10143 iOS: handle device orientation change
↧
↧
Source code checked in, #4864add24799
iOS: correct text measurement (use CTLine.GetImageBounds)
↧
Source code checked in, #0c0226c31fc3
iOS: add basic example (SimpleDemo)
↧
Source code checked in, #e8b3f339f310
iOS: add launch images to example browser
↧
