I have a large federated model loaded in Autodesk Forge Viewer (~300k elements from several IFC files). I'm doing a cross-model (aggregate) selection like this:
var selection = [{model1 : [ids...]}, {model2 : [ids...]}, {model3: [ids...]}, etc...);
viewer.impl.selector.setAggregateSelection(selection);
Now, given that the number of selected elements goes to 100k+, this freezes the UI for a couple of seconds, then once all of the elements get highlighted in the viewer the performance (fps) of the viewer degrades significantly. Switching to isolation instead of selection (highlighting) improves viewer performance but it still freezes the UI for a couple of seconds while doing it.
Are there any performance tips when doing these large selections, can the selection/isolation process be done async so the UI feels more responsive?
Cheers
I'm afraid the selection mechanism (both the state toggling and the rendering) isn't optimized for such numbers, and there's no way to optimize it yourself. This would require a code update in the internal viewer implementation.
Before we pass this to the engineering team, however, I would like to ask about your actual use case. The selection functionality is typically used to bring user's attention to one (or a small number) of elements in the design, or to allow the user to choose one (or a small number) of elements for some further processing. But selecting 100k+ elements, and then continuing the use of the viewer with those 100k+ elements selected? What exactly do you need that for? Have you considered using other features of the viewer such as the theming colors?
Related
I'm allowing users to select an icon from the full list of FontAwesome icons (using a List<ImageVector>). I'm going to open a dialog, and show the icons as IconButtons arranged in the list. There are ~1600 icons.
I implemented it using a LazyVerticalGrid, with a fixed number of columns. It works, but there's some lag loading the icons, and lag when scrolling the icons.
I'm converting this from a React Native project where I did the same thing (with a larger set of icons, actually) and scrolling that was pretty snappy, so I'm assuming it's possible to do performantly on native. Perhaps ImageVectors are heavier than the SVGs I was using in React Native?
I'm planning to provide a search box in the dialog where users can filter the list down by doing a fuzzy search on icon names, so the grid will change over time.
What sort of patterns should I be looking at here? Is LazyVerticalGrid the way to go, or should I be using a different approach entirely?
On Laziness
For an overview of use cases and appliable patterns you might be interested in the Android Dev Docs' page on Lists and Grids, încluding the topics Large data-sets (Paging) and the Tips on using Lazy layout.
This might wake your interest on the Android Jetpack Paging Library androidx.paging, which is designed for loading and displaying pages from large datasets, basically uniting the concepts of Laziness and Caching.
Currently you're only using Laziness. As Bartek Lipinski commented, that should usually be fine when the graphics to display are static. However, when they have to be loaded asynchronously, Paging will probably improve your performance.
Some Rules of Thumb
Scrolling
Pattern
No
Column or Row will be enough
Some
Column or Row with modifiers verticalScroll and horizontalScroll
More, static content
LazyColumn or LazyRow, resp. for gridding LazyVerticalGrid or LazyHorizontalGrid
More to mass, dynamic content
LazyColumn or one of its relatives with LazyPagingItems, so using the Paging Library androidx.paging
Also, as the docs say, consider adding contentType
. However, as Bartek Lipinski remarked, one usually benefits of contentType when there are scrollable elements of various types -- not only SVGs as maybe in your case. Still, giving hints to the system doesn't hurt, at least.
On Vector Graphics
As discussed in the comments, esp. by Subfly and Bartek Lipinski, though Laziness should be the main thing here, another bottleneck could be the loading of vector graphics during runtime.
If the graphics used are of static nature, then consider the usage of vector graphic assets. Those are supported for SVG and PSD since Android 5.0 (API level 21). Take also a look on the recommendations and some aspects of support and restrictions on SVG.
Summary
The basic formula is Laziness + Vector Assets with focus on the first. One might spice that with contentType and Paging.
I'm in the need of an Excel like grid in an attempt to convert an "application" written in Google Calc to a real application. I've got one implementation using Vaadin, but it (also) suffers from a long page construction. The screenshot below uses a CSS flex grid with individual divs, and given 6 weeks, there are over 5000 individual divs.
Constructing this page takes over 20 seconds, not something users will be happy about. I'm working on a version based on a table, but it does not seem to improve much. In the end the same amount of cells need to be constructed, whether they are DIVs or TDs does not seem to matter much.
Is there a way to construct such a grid in a more speedy way? I'm more than happy to solve "where did the user click?" on the server side. To be aware of: besides the number of cells themselves, each also has specific content, so just getting a grid shown is not enough.
Each component (div, or something else) is managed by the server. So when you have 5000 of them it's quite slow. You need to reduce the number of components managed by the server.
I can't give you a better answer since I don't know the requirements. But the idea is to try to combine some elements.
You have an example of a table generated ( instead of each element one by one) here: https://cookbook.vaadin.com/grid-details-table.
You can also create or own component. There is also a paid add-on: spreadsheet which seems to fit your needs. It's still in preview: https://vaadin.com/roadmap
The problem here is the complexity of the UI itself. Rendering 5000+ cells will be slow what ever method you use and what ever framework you use. There will be big amount of elements in the DOM and you need to load also lot of data upfront. And as you see the result is huge, and it wont fit most screens. So I would recommend further design of the UI. Is it really necessary to show all the weeks at once? Your UI's complexity will already reduce a lot if you show only one week at the time and add buttons to browse the weeks forwards and backwards. But even with that optimization you will have lot of columns. I would consider adding another browsing direction by day. Further knowledge of the actual purpose of the UI will naturally give more insight how to develop it further.
In brief: I've got a page with KO-code that operates absolutely cool in Google Chrome, Firefox, Safari, etc. But the performance is gone in Internet Explorer. I tried IE10, IE11. It takes from 10 to 25 seconds to render about 150 rows.
Details: There page represents a work queue for users, where their tasks are shown. The requirement is not to use any paging on that page. Each row of the table has at least a dozen of variants to display (links, buttons, inputs, css styling, handling user events, custom js plugins, etc.). The average number of rows on prod is 100-200+. User is able to apply different filters and sortings.
Things I've already tried:
reduced the number of computed properties (changed to pureComputed, where possible)
reduced the number of using the template, if and ifnot bindings (according to profiler they are the most time consuming task) - I use the visible, where possible
tried to use the knockout-fast-foreach custom binding (https://github.com/brianmhunt/knockout-fast-foreach)
profiled the code with IE and Chrome tools to eliminate the memory leaks
profiled the code with ko.bindingReport.js (https://gist.github.com/kamranayub/65399fa247a6c182bc65)
The approaches specifed above tuned the code (according to ko.bindingReport.js) almost two times faster in Chrome. But IE is still too slow - about 10 seconds for rendering.
Chrome:
Internet Explorer:
Folks, any ideas?
"The table binding provides a fast method for displaying tables of data using Knockout. table is about ten times faster than nested foreach bindings."
This claims to be 10x faster.
https://github.com/mbest/knockout-table
You reduced the amount of computed observables, but did you also reduce the amount of observables? I'm not seeing a lof of editable fields. The ones that are not being edited on the page probably don't need to be an observable? This has boosted my performance quite a lot of times.
Our engineering department wastes a great amount of time reviewing drawings for errors. The majority of these problems involve human errors in labeling (ie. two rooms have the name 01-01-00-RM). Our IT department has come up with a partial solution by automation the room names. However, the engineers still have to type this into AutoCAD.
Is there any way to create labels in AutoCAD based on another file (ie. an Excel/CSV document)? Ideally, one would create a group in a layer and enforce that all elements be unique, then have them retrieve their values from a document.
EDIT
Some screenshots of the labels. Note, for company reasons, I can't put full PDF screenshots up.
First image showing compact label next to a camera. This was on a floor plan overlay.
Second image showing the full lable next to a camera. This was in the block diagram
Yes it's possible, there some different paths:
Lisp: very common on AutoCAD environment and allow some basic (and not so basic) automations.
VBA/COM: can be used from inside AutoCAD or by external process, just need to CreateObject("Application.AutoCAD") and program the steps
.NET or C++: in-process automation that allow powerful customization, up to a major remodeling of AutoCAD.
So, depending on your expertise, you may choose different approaches. It may also combine with batch processing via AutoCAD Console.
Find more at http://www.autodesk.com/developautocad and at the blog http://adndevblog.typepad.com/autocad
If the labels were blocks with attributes then you could use the ATTOUT and ATTIN commands in Express tools to export / import them in to/out of Excel. Watch for cell formatting in Excel - eg. numbers like 1/2 turn into dates if you leave the formatting as "General".
Programmatically this is reasonably trivial if the data is structured. An AutoCAD drawing is actually a hierarchical object database so everything in it is addressable, finding it is often the hardest part. If you have an AutoCAD installation handy, have a look into a drawing with MGDDBG to get an idea of the database structure.
I have a gwt list grid which i need to show more than 1000 messages.
But it takes 40millsec to display each message. So it is very slow.
Can u help me so that i can show all messages in less time.
Thanks Nagaraju
As Bogdan said paging is your best bet.
However if your requirement strictly needs you to have the 1000+ lines at one time I would reconsider the grid approach.
When you are working with such a large amount of elements an iterative dom "touch" will be dirt slow.
See if you can rather create a component that gets the messages into String form with their markup. Then set the inner HTML once. You can then use something like jquery or gwtquery to attach handlers to the elements in a timely fashion.
Failing that you could use a lazy render method where you render only whats on-screen but that gets much more complicated.
Answering this 2 Year old question Just for Kicks -
GWT has progressed a lot since 2 Years.
GWT provides hell lot of options to User to do performance tuning.
GWT as done a lot of perormance tuning on widgets. GWT 2.5 has Cell
Widgets like CellList/CellTable/DataGrid which make displaying large
data easier , faster and with light weight heavy DOM.
Reference -
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiCellWidgets
Summary -
Cell widgets (data presentation widgets) are high-performance, lightweight widgets composed of Cells for displaying data. Examples are lists, tables, trees and browsers. These widgets are designed to handle and display very large sets of data quickly. A cell widget renders its user interface as an HTML string, using innerHTML instead of traditional DOM manipulation. This design follows the flyweight pattern where data is accessed and cached only as needed, and passed to flyweight Cell objects. A cell widget can accept data from any type of data source. The data model handles asynchronous updates as well as push updates. When you change the data, the view is automatically updated.
In addition, cells can override onBrowserEvent to act as a flyweight that handles events that are fired on elements that were rendered by the cell.
Note -
1) CellTable being capable of displaying large data also come with Pager options and also AutoPage on Scrolling option ( example CellList )
2) Also, if you come across any other performance issues in GWT you can call in the Bazooka features of GWT - SpeedTracer, Logging, Chrome Dev tools Profiling, GWT Light Weight Metrics, Code Splitting, GWT Compiler Metrics, GWT Closure Compiler, Resource Bundling to crush it !!!!
1000 items for a web-based application is too much. Try implementing some sort of paging algorithm. You could look at the PagingScrollTable from gwt incubator ;)