Lightweight charts .fitContent() doesn’t work when there is just a few data points - lightweight-charts

I’m trying to create chart with just few data points but seems that LightWeight charts cannot handle situation when there is less then 10 data points a fit content correctly to full width with .fitContent() method.
Example: https://jsfiddle.net/ekfLzmo6/
Is there anyway that I can fit content properly to 100% of canvas?

Related

Angular: moving charts into different bindings

New developer here working on some thing that's a little out of my depth.
I'd like to have dynamically generated charts into rotate into different, predetermined locations on my page.
for example:
chart 1
chart 2
chart 3
would rotate thru a list of 5 charts to display
chart 2
chart 3
chart 4
I feel like my best option here is to create objects (JSON maybe?) of these charts and to have them stored in an array, then have the array loop through the binding locations and 'plop' (for lack of better word) the object's details into the next spot in the rotation, which theoretically would allow the chart to render in the new location; with a timer driving the changes.
I would probably use pre-set frames to designate the slots being rotated into, though I'm less positive that is the right way to handle that.
I know this is possible with angular, and despite my best efforts I cannot for the life of me determine the best way to go about this. I'm really very open as to the method this gets done, but am at a complete loss on how to set up the data-binding framework to accomplish this.

Efficiently display multiple markers on WPF image

I need to display many markers on a WPF image. The markers can be lines, circles, squares, etc. and there can be several hundreds of them.
Both the image source and the markers data are updated every few seconds. The markers are associated with specific pixels on the image and their size should be absolute in relation to the screen (i.e. when I move the image the markers should move along with it, but if i zoom in, they should take the same space of the screen as before).
Currently, I've implemented this using the AdornerLayer. This solution has several problems but the most significant one is that the UI doesn't fare well under the load even for 120 such markers.
I wanted to ask what would be the best way to go about implementing this? I thought of two solutions:
Inherit from Canvas and make sure it is invalidated not for every
added marker but for a range of markers at once
Create a control that holds an image and change its OnDraw to draw all the markers
I would appreciate some pointers from someone with experience with a similar problem.
Your use case looks quite specialized, so a specialized solution seems in order. I'd try a variant of your second option — extend Image, overriding its OnRender method.

How to get a snapshot of a WPF element in varying sizes without affecting the Quality of Curves and Text rendered?

I am working on a chart control in WPF.
I need to implement a functionality to take a snapshot of Chart in any input size without affecting the quality of Curves and Texts rendered on it.
The functionality is already implemented, but now problem is, while taking the snapshot using FrameworkElement.Transform() screen flickers as the actual control is getting resized and re-rendered.
Can anyone suggest me a solution or a pointer to work on to eliminate the problem. One important thing to mention is the data to be rendered on Chart is huge due to which it takes some time to re-render the data on Chart.
Any kind of help is much appreciated.

Issues with rendering a large tiled map in WPF

What is the best way to manage a very large amount of images (10,000+) in WPF? This is for a 2d tile map editor similar to this : http://www.mapeditor.org/ .
At the moment i have a canvas with all tiles as an image and a list box which contains the different images to choose from. Each tile is added to the canvas as children and then stored in a list for later access. You paint into the canvas by setting the Source property of a tile to the one selected in the listbox. It works well with around 50x50 tile maps but anything above that causes loading delays, in general slow application.
Any suggestions on this? Would QT maybe be more suited instead of wpf?
Thanks in advance
Check out Implementing virtualized panel series of articles.
Virtualized panels are efficient, because:
Only the displayed elements (and a few extra around the borders to enable smooth scrolling) are in the memory (and rendered).
Elements are reused, instead of being repeatedly created and discarded - an old cell is simply filled with new content (supplied with new DataContext) and used in new location.
You might also try to use WPF's DataGrid for this, it supports virtualization out of the box and is essentially what are you trying to do.
WPF is certainly able to do this, if implemented properly (if you can do that in JavaScript, you can certainly do it in WPF as well).

What is the best approach to render charts in WPF?

What is the best approach to render charts and then save them on a hard drive for further distribution using WPF?
I found a number of ways to accomplish this by using the following types:
DrawingVisual - creating a object of this type and then rendering graphics on its context;
Shape - deriving from the Shape class and then overriding its DefiningGeometry property where the actual rendering is happening;
PathFigure - adding LineSegment-s to an instance of this class and then adding this instance to a Canvas;
Adorner - deriving from it and then overriding its OnRender method;
WritableBitmap - rendering on it and then adding the bitmap to a Canvas.
Of course I'm going to write an app to test how fast each of these will be. But can anybody tell me:
whether am I on the right track?
are there any other means to do such rendering?
which one of them is the best in
terms of performance?
It all depends on your actual usage, in your case you mention saving on the hard drive for "further distribution" - I'm going to assume you are saving them as an image (jpg or png) and not as wpf objects (xaml).
You should consider if WPF is the right tool for the job, WPF is a UI framework and not a generic image processing library, it may be best to use something else entirely for generating images.
For a reasonable number of points your performance bottleneck will be encoding the image and saving it to disk - not actually rendering it - so you should choose the method that is easier for you to code.
All the articles about high performance WPF charts are a: about charts with 10,000 points and more (because that is where the performance problems are), b: about charts you display in your GUI (because otherwise you can use an image processing library to create the bitmap) and c: charts that change all the time (so they work nicely with data binding) - there's a reason why they don't talk about saving charts to disk.
For a very large number of points:
The fastest way to draw in WPF is to inherit from FrameworkElement (not Adorner) and override OnRender.
When the data changes often it is recommended to use multiple DrawingVisual objects because then you don't have to re-render everything when one value change - but this is not relevant for you since the image won't change after you save it anyway.
WritableBitmap is used for raw bitmap access, you use it when you decide to give up on all the nice layout and drawing WPF gives you because you can't take the overhead, if this is the case you should re-read my first point above.
So, to summarize, you are asking the wrong question :-) if you need to save images to disk than either the WPF rendering speed is not your bottleneck or you shouldn't be using WPF to begin with. If you do use WPF just pick whatever is easiest for you to code.
BTW: Adorners are used to display "floating" elements above the normal UI, you can use them for tooltip-like features but not for the main chart rendering (and you probably don't want them at all since your main usage is saving the image to disk), FrameworkElement is the base class you are looking for.

Resources