LightningChart Support Forums

I am curious what is the minimum requirements for lightningChart Ultimate. I turned on ThrowChartExceptions to see if I could pin point the cause of a mysterious crash in my program. When ever the application starts up I get the following exception:
Arction.WPF.LightningChartUltimate.ChartException: Warning: The control can't be rendered with optiaml settings.
Your display adapter does not support all features needed.
The graphics quality or rendering performance is not optimal
You should consider upgrading your display adapater.

I am wondering at what minimum display adapter does this exception stop appearing? And could it cause the chart to crash if I am using a sub pair video card.

As a note the adapter in the laptop I use at work is NVIDIA Quadro FX 3800M which is a Direct X 10 card.

Regards,
Aaron

It is a warning only, and indicates that the GPU doesn't support all features that LC takes advantage of. It doesn't cause a crash.

Requirement is a DirectX 9.0 c level or better GPU. Your NVidia fulfills that requirement just fine. The warning is given because it doesn't have support for FastVertexFormat we use in 2D rendering. That format is supported by Ati/AMD GPUs only. For Nvidia and Intel, we use a different (slower) vertex format.

I suspect the reason for the crash is in the threading of the application (forgetting to use Invoke when updating from a thread). Ensure your GPU drivers are up to date.

I noticed in that control that I had turned of the ChartRenderingOption.UseThreadPool but set LC to use AllAvialableCores. I agree that the crash I am experiencing seems like a threading issue because it happens very infrequently however I am fairly convinced it is happing on LC's end because there is no exception being thrown, the app just will experience a CLR crash and stop.

I'm quite convinced the multi-threading is correct in LC side, let it be UseThreadPool enabled or disabled.

Can you produce crash on that system by using LightningChart demo application?

Please check that you using Dispatcher.Invoke when you update data or properties of the chart, otherwise it will crash sooner or later.

If the chart is created on the UI thread and all maniuplation coming to it is coming from mouse events why does it require a Dispatcher.Invoke ?

Also this type of error usually produces the exception "The calling thread cannot access this object" which I can correct swiftly. The error we have been see'ing will not produce a error rather will just shut down the application. Since there is no message when it crashes I cannot be 100% sure it is LC but I know its only happened while manipulating the chart.

symbolick wrote:If the chart is created on the UI thread and all maniuplation coming to it is coming from mouse events why does it require a Dispatcher.Invoke ?

I intended to say, when you update from a thread on your side, Invoke is needed.

symbolick wrote:Also this type of error usually produces the exception "The calling thread cannot access this object" which I can correct swiftly. The error we have been see'ing will not produce a error rather will just shut down the application. Since there is no message when it crashes I cannot be 100% sure it is LC but I know its only happened while manipulating the chart.

If your thread updates UI and Invoke is not used, it can crash usually in the following ways
- App just closes
- Gives memory read/write error
- Complains about DirectX resource access


Please add the following routine to beginning of all methods you are updating the chart without Invoke. Then set a breakpoint on the WriteLine row. If it comes there, Invoke has to be used there. Find the reason for the crash, then you can remove this check.

Thanks for the checkaccess code, after using that I can see that the control is not being accessed from a background thread. One thing to note when I turned the threadpool bool back to true, the crash seemed to stop occurring. It was a very rare crash(sometimes 30 minutes or more of manipulating the chart would not reproduce it) and the only reason we even got to see it happen somewhat often was that the software was being used by a large group of people.

Crashing is not acceptable and it's great if enabling ThreadPool solves the case. Using ThreadPool is faster than regular thread spawning and therefore crash is less likely to occur. So I still have some doubts about the effectiveness of the fix. The chart execution always is synchronous inside and ThreadPool as well as regular spawning to several threads always catch the exiting threads before exiting the chart rendering routine.

What kind of chart are you using by the way? XY line chart? Scatter chart? IntensityGrid, 3D Surfaces? If there really is a problem in the chart, we really appreciate your help finding how to reproduce it.

The chart I am using is a ViewXY, depending on what the user does they can have from a single AreaSeries up to 2 AreaSeries, a LineSeries, Polygon Series, Some Band's and AnnotationXY's. The crash seemed to happen when the user was interacting with the chart (hardly ever the same interaction) such as panning or mousing over a axis. I will need to wait some time (probably a week or two) to be completely sure that there is no longer a error. Like I said I am sure its not being accessed on a background thread but there is alot of our code going on in the background(computations to decide what to display) so with the lack of a error message or it breaking in visual studio (it just exits) I cannot rule out that it could be something else.

Best Regards,
Aaron

OK, thanks.

If you want to track the problem more precisely, by setting additional log writing features or debug inside LightningChart code, consider upgrading to source code option. The code is very handy to have in those cases.