I have to deal with very big data sources lately and was wondering if there was a way to increase the performance of GoJS.
GoJS is very efficiently processing my data, and the TreeView I am trying to make is displayed shortly after the site is fully loaded. Unfortunately, when panning the view, the diagram somehow begins to lag a little.
I am now looking for a way to decrease that lag to a minimum.
I tried fiddling with the Layout options but it did not result in significant performance increase.
To the diagram, I have a diagram with "relatively" few nodes (498 to be precise), but my template is unfortunately rather complicated. It has a nested itemArray, which generates rows and columns inside that row. Another thing is that I use a slightly modified version of the "LayeredTreeView" model.
These nodes are in 388 invisible groups. Generating it without using layout things like crossing reduction only takes a moderate amount of time.
Also i have just discovered the performance site of the GoJS introduction. It has been mentioned there, that complex templates make GoJS slow. Could this here be the case?
Complicated templates take longer to build than simple ones, so the loading time will take longer when the nodes are complex and detailed.
However, once all of the Nodes and Links have been created and initialized in the Diagram, scrolling (a.k.a panning) should be pretty fast.
Virtualization decreases load time because there should be very few nodes and links to create and show initially. However virtualization does slow down scrolling and zooming because nodes and links have to be created as the viewport changes. And as that Performance page suggests, implementing virtualization requires a lot more programming work. And it might not even be feasible or faster, depending on the circumstances.
Related
I'm working on an app for scheduling projects. One of its main features should be displaying currently logged users' cursors in realtime. Like in Figma:
On the backend, I'm going to use Firebase Realtime Database, where I'm gonna store mouse cursor coordinates. But, I've got a problem with the frontend part - I'm wondering what will be the best approach when it comes to the way of displaying them?
The most common solution is to use html canvas, but I'm afraid that this will mean, that I'll have to totally rebuild my app frontend ;)
So maybe just some small divs / svg elements representing other users' cursors? With this solution, I'm afraid that cursors will cover interface elements, so it will not be possible to click on those elements. Maybe it will require playing with z-index?
Please let me know, what in your opinion will be the best approach.
Canvas is the best option here. You can use it as a layer above the rest of the page and as mentioned in the comments set pointer-events :none; to make sure it doesn't interfer with the other page functionalities.
Changing multiple SVGs positions in high frequency sounds inefficient performance wise, it will send the render process to reflow stage.
Here is a great explanation of the browser render process
Here you can find the following explanation:
To ensure smooth scrolling and animation, everything occupying the main thread, including calculating styles, along with reflow and paint, must take the browser less than 16.67ms to accomplish. At 2048 X 1536, the iPad has over 3,145,000 pixels to be painted to the screen. That is a lot of pixels that have to be painted very quickly. To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several layers. If this occurs, then compositing is necessary.
Painting can break the elements in the layout tree into layers. Promoting content into layers on the GPU (instead of the main thread on the CPU) improves paint and repaint performance. There are specific properties and elements that instantiate a layer, including and , and any element which has the CSS properties of opacity, a 3D transform, will-change, and a few others. These nodes will be painted onto their own layer, along with their descendants, unless a descendant necessitates its own layer for one (or more) of the above reasons.
Layers do improve performance, but are expensive when it comes to memory management, so should not be overused as part of web performance optimization strategies.
(Meaning that you can create a layer for SVGs, but you'll have to use transform to move them around instead of top/left)
Best of luck with your project:)
I grew up using JQuery and have been following a programming pattern which one could say is "React-like", but not using React. I would like to know how my graphics performance is doing so well, nonetheless.
As an example, in my front-end, I have a table that displays some "state" (in React terms). However, this "state" for me is just kept in global variables. I have an update_table() function which is the central place where updates to the table happen. It takes the "state" and renders the table with it. The first thing it does is call $("#table").empty() to get a clean start and then fills in the rows with the "state" information.
I have some dynamically changing data (the "state") every 2-3 seconds on the server side which I poll using Ajax and once I get the data/"state", I just call update_table().
This is the perfect problem for solving with React, I know. However, after implementing this simple solution with JQuery, I see that it works just fine (I'm not populating a huge table here; I have a max of 20 rows and 5 columns).
I expected to see flickering because of the $("#table").empty() call followed by adding rows one-by-one inside the update_table() function. However, the browser (chrome/safari) somehow seems to be doing a very good job of updating only that elements that have actually changed (Almost as if the browser has an implementation of Virtual DOM/diffing, like React!)
I guess your question is why you can have such a good graphics performance without React.
What you see as a "good graphics performance" really is a matter of definition or, worse, opinion.
The classic Netscape processing cycle (which all modern browsers inherit) has basically four main stages. Here is the full-blown Gecko engine description.
As long as you manipulate the DOM, you're in the "DOM update" stage and no rendering is performed AT ALL. Only when your code yields, the next stage starts. Because of the DOM changes the sizes or positions of some elements may have changed, too. So this stage recomputes the layout. After this stage, the next is rendering, where the pixels are redrawn.
This means that if your code changes a very large number elements in the DOM, they are all still rendered together, and not in an incremental fashion. So, the empty() call does not render if you repopulate the table immediately after.
Now, when you see the pixels of an element like "13872", the rendering stage may render those at the exact same position with the exact same colors. You don't have any change in pixel color, and thus there is no flickering you could see.
That said, your graphics performance is excellent -- yes. But how did you measure it? You just looked at it and decided that it's perfect. Now, visually it really may be very very good. Because all you need is avoid the layout stage from sizing/positioning something differently.
But actual performance is not measured with the lazy eyes of us humans (there are many usability studies in that field, let's say that one frame at 60 Hz takes 16.6 ms, so it is enough to render in less than that). It is measured with an actual metric (updates per second or whatever). Consider that on older machines with older browsers and slower graphics cards your "excellent" performance may look shameful. How do you know it is still good on an old Toshiba tablet with 64 MB graphics memory?
And what about scaling? If you have 100x the elements you have now, are you sure it will scale well? What if some data takes more (or less) space and changes the whole layout? All of these edge conditions may not be covered by your simple approach.
A library like React takes into account those cases you may not have encountered yet, and offers a uniform pattern to approach them.
So if you are happy with your solution you don't need React. I often avoid jQuery because ES5/ES6 is already pretty good these days and I can just jot down 3-4 lines of code using document.getElementById() and such. But I realize that on larger projects or complex cases jQuery is the perfect tool.
Look at React like that: a tool that is useful when you realize you need it, and cumbersome when you think you can do without. It's all up to you :)
When you have something like this:
$("#table").empty()
.html("... new content of the table ... ");
then the following happens:
.empty() removes content and marks rendering tree / layout as invalid.
.html() adds new content and marks rendering tree / layout as invalid.
mark as invalid among other things calls InvalidateRect() (on Windows) that causes the window to receive WM_PAINT event at some point in future.
By handling WM_PAINT the browser will calculate layout and render all the result.
Therefore multiple change requests will be collapsed into single window painting operation.
I'm working with ChemDoodle library for rendering complex chemical structures. Everything works fine, but with big molecules (about 20k atoms) it's working quite slow. I don't have much experience in graphics, but I think it might me because each atom is rendering independently - every time it's rerendering, it has to iterate over array of atoms (it should be buffered).
My idea was to create some structure, that would be calculated on init time and when render, only camera would change it's position. I don't need to manipulate with atoms, only use mouse to rotate/move whole molecule. Is something like this even possible and would it improve performance?
I would appreciate info if it's possible (or some other suggestions), ideally in pure WebGL, without ThreeJS..
I am trying to make a browser-based tool that lets you inspect dependency graphs as they appear in module systems of programming languages and Makefiles.
I am looking for a visualization framework that does the drawing for me.
The requirements are that the toolkit can
label nodes (and hopefully edges)
automatically space out the graph to the right size (I don't have to guess good dimensions) given that I have infinit space (scroll bars are fine)
layout the graph nicely so that it doesn't look as messy
be fine with <= 5000 nodes
run with JS only (no Flash or desktop apps)
Optionally, it would be nice if it made it easy to move nodes around and highlight or hide parts of the graph for better overview.
It does not matter much what backed is used (SVG, canvas, all fine).
I have looked at quite a few libraries so far (especially from Graph visualization library in JavaScript), but not found a fitting one yet:
d3 is nice but the only node-graph it delivers is a force graph, which is focused on real time physics. Once loaded, you have to wait and watch for the physics engine to stabilize. I don't need animations nor the Force, and want to show the graph right away.
GraphDracula's examples are pretty much what I am looking for, but already with 70 nodes and 400 edges, the drawing performance becomes really bad. It also has very little documentation (being a 35 line code example).
Do you know something that meets my requirements? Thanks!
In a commercial scenario you might want to consider yFiles for HTML:
Regarding your requirements it can:
Add any number of labels to nodes and edges
Provide virtually infinite scrolling/panning/zooming area
Layout your graph automatically using a great variety of automatic layout algorithms. For dependency graphs, the Hierarchic Layouter is very well suited
works nicely on desktop browsers with larger numbers of nodes. Depending on the visual complexity and graph structure, 5000 elements might proove difficult with todays browser implementations, though.
It's a pure Javascript library with no dependencies whatsoever
Uses SVG as the main backend, but can also leverage Canvas
The library is well documented, which is necessary given its complexity
Here is a screenshot showing some of the above features in action - the layout was calculated automatically:
Disclaimer: I work for the company that creates the library. On SO/SE I do not represent my employer. This is my own post.
Dagre works pretty well for graph layout (horizontal/vertical alignment, labels, etc.) and has D3 renderer.
https://github.com/cpettitt/dagre-d3 (check images at the end)
https://github.com/cpettitt/dagre
I'm working off of designs which show a scrollable box containing a list of a user's "contacts".
Users may have up to 10,000 contacts.
For now assume that all contacts are already in memory, and I'm simply trying to draw them. If you want to comment on the question of how wise it is to load 10k items of data in a browser, please do it here.
There are two techniques I've seen for managing a huge list like this inside a scrollable box.
Just Load Them All
This seems to be how gmail approaches displaying contacts. I currently have 2k contacts in gmail. If I click "all contacts", I get a short delay, then the scrollable box at the right begins to fill with contacts. It looks like they're breaking the task into chunks, probably separating the DOM additions into smaller steps and putting those steps into timeouts in order to not freeze the entire interface while the process completes.
pros:
Simple to implement
Uses native UI elements the way they were designed to be used
Google does it, it must be ok
cons
Not totally snappy -- there is some delay involved, even on my development machine running Firefox. There will probably be quite a lot of delay for a user running a slower machine running IE6
I don't know what sort of limits there are in how large I can allow the DOM to grow, but it seems to me there must be some limit to how many nodes I can add to it. How will an older browser on an older machine react if I ask it to hold 10k nodes in the DOM?
Draw As Needed
This seems to be how Yahoo deals with displaying contact lists. The create a scrollable box, put a super-tall, empty placeholder inside it, and draw contacts only when the user scrolls to reveal them.
pros:
DOM nodes are drawn only as needed, so there's very little delay while loading, and much less risk of overloading the browser with too many DOM nodes
cons:
Trickier to implement, and more opportunity for bugs. For example, if I scroll quickly in the yahoo mail contact manager as soon as the page loads, I'm able to get contacts to load on top of one another. Of course, bugs can be worked out, but obviously this approach will introduce more bugs.
There's still the potential to add a huge number of DOM nodes. If the user scrolls slowly through the entire list, every item will get drawn, and we'll still end up with an enormous DOM
Are there other approaches in common use for displaying a huge list? Any more pros or cons with each approach to add? Any experience/problems/success using either of these approaches?
I would chunk up the DOM-writing into handle-able amounts (say, 25 or 50), then draw the chunks on demand. I wouldn't worry about removing the old DOM elements until the amount drawn gets quite large.
I would divide the contacts into chunks, and keep a sort of view buffer alive that changes which chunks are written to the DOM as the user scrolls through the list. That way the total number of dom elements never rises above a certain threshold. Could be fairly tricky to implement, however.
Using this method you can also dynamically modify the size of chunks and the size of the buffer, depending on the browser's performance (dynamic performance optimization), which could help out quite a bit.
It's definitely non-trivial to implement, however.
The bug you see in Yahoo may be due to absolutely positioned elements: if you keep your CSS simple and avoid absolutely/relatively positioning your contact entries, it shouldn't happen.