There is a huge scroll performance issue if ag-grid is used with custom header component and custom cell renderers. We tried with about 10000 rows x 10000 columns. Without custom renderers, it is running smooth. Custom cell renderers is causing an overall performance issue and applying only custom header is causing horizontal scroll issue(vertical scroll is fine). We are using ag-grid-react. Is there any issue with ag-grid if used with other framework components instead of default components?
We faced similar issues while using custom components in Editable ag-grid, even though our data was ~1000 rows and ~20 columns.
We gained a major bump in performance by porting our custom components from cell renderers to cell editors.
During this journey I studied about how ag-grid internally works and found out that by default virtualization is enabled in ag-grid, which means whenever you scroll, some of your components gets mounted and some gets un-mounted. If you consider it for lot of components, it's a really heavy operation.
Before trying the approaches discussed on official docs, I would recommend you to increase the rowBuffer and see if you gain any performance and if you're, like us, using some editable components as cell renderers then port those to cell editors.
Related
We currently use react-base-table as our solution for an infinitely scrolling table component, but it runs into performance problems with a large number of columns because it does not virtualize horizontally. My understanding is that ag-grid does, so we are looking at it for primarily performance reasons.
Our app defaults to displaying data (log events) from bottom to top. The user is initially placed at the bottom of a potentially large virtual dataset (could be millions of events), and they scroll up to load and view more events (200 at a time).
After reading through ag-grid docs and searching here, I don't see anything about support for an upward direction for infinite scroll. Am I missing anything?
I've tried implementing it with the default row model, but am running into errors (eg "cannot draw while in the middle of drawing rows"). The 'onViewportChanged' event I'm using to trigger a fetch is called several times when rendering, and messes up our data model. Infinite scroll seems like the correct approach.
Yes, it is possible.
You will need to set serverSideInitialRowCount={1000} so the grid could adjust scroll size. And then in the onGridReady event call api.ensureIndexVisible(999).
The grid will request only the last data block, and will request other blocks as you scroll up.
I have a grid view which is showing the heal status of many different services, and coloring them and/or auto-opening a webpage when the service goes down. The problem is that the elements which are off the screen are not being checked, which is more efficient, but not what is desired in this case.
I guess it's behaving similarly to the RecyclerView in android?
I want to be building the widgets which are checking service health even when they are not visible on the screen.
Currently the services don't start being checked until the moment I scroll them into the screen.
Assuming you are currently using the GridView.builder constructor, I recommend using the "normal" GridView constructor (with a children property). Since GridView.builder only builds the elements currently visible for efficiency reasons, the elements that are not rendered on the screen won't run your back end logic.
For more information, see the official docs:
[GridView.builder] constructor is appropriate for grid views with a large (or infinite) number of children because the builder is called only for those children that are actually visible.
Here you'll find alternatives:
The most commonly used grid layouts are GridView.count, which creates a layout with a fixed number of tiles in the cross axis, and GridView.extent, which creates a layout with tiles that have a maximum cross-axis extent.
I am building calendar based app and trying Flutter.
Can you give advice/example of hierarchy how build complex and efficient layout like Google Calendar daily view?
Main question: how should I layout constant hours background and overlapping dynamic events layer?
I used RecyclerView and custom RecyclerView.LayoutManager before, but have no idea about Flutter way.
You can construct your layout efficiently using GridView.custom.
A custom SliverGridDelegate can produce an aribtrary 2D arrangement of children, including arrangements that are unaligned or overlapping.
An easier option might be to use a CustomMultiChildLayout but that will require laying out all the children instead of just the ones that are visible. It could be slower, but maybe that isn't the bottleneck for a calendar app.
I am currently trying to get the hang of Auto-layout in Xcode, and with it, i have found some problems.
Now, i don't have a 100% grasp on how auto-layout works exactly, so as i learn on it might become easy, but i think it is very hard to be honest. I am usually making games, and of thus, i programmatically add a lot of views to the screen. Now, auto-layout seems to mess everything up when i do this, so i constantly have to make sure that every single auto-layout feature is just right, and there are a bunch!
So, if you do not want to support other orientations, is auto-layout really needed? i mean, if i am making a game for the iPad and using landscape mode only, is there any reason for me to use auto-layout?
Thanks on advance
A couple of thoughts:
Auto layout is not mandatory.
But auto layout provides a mechanism for dealing with situations when views change sizes and/or locations:
changing orientation, as you pointed out;
supporting different screen sizes (e.g. iPhone 3.5" screen vs 4.0" screen);
controls whose size changes based upon content (e.g. a UILabel whose width expands to fit the text or whose lineCount is set to zero, meaning that its vertical will grow based the number of lines needed to fit all the text); with auto layout you can establish dependencies between controls so that, for example, as one control changes its own size/location, others can move/resize accordingly (e.g. to stay aligned with or make room for the other control); and
automatically update contentSize for UIScrollView objects.
Auto layout requires a little time to gain proficiency, but for dynamic, complex user interfaces, it can save you from having to write code to manually change layouts of views programmatically. But if you don't find yourself doing this sort of code, then you don't necessarily have to use auto layout.
I should acknowledge that there are some tasks that are trivial in a non-autolayout environment (e.g. animation of moving views), doing the same task in auto layout can be frustratingly complicated. But if you have complex interdependencies between views (either between the superview and its subviews or between sibling views), auto layout can be useful.
Autolayout simply provides rules for the views how they appear in all orientation.It is upto the user to define how to use it or you may follow the struct and spring model .
The major difference between the two is that there no dimensions involeve in the struct and springs while autolayout says the dimensions and values in whch views should be rearranged
An excellent beginner tutorial fo autolayout
I'm trying to implement a view that shows a grid of information without using a UITableView, however, since I'm displaying about 36 different statistics, with its label I will have to initialize and use 72 UILabels. Does having so many UILabels mean that my iPhone app's performance will be significantly negatively affected? Is there a way to reuse some of the UILabels to decrease the number of UILabels that must be loaded at one time, or should I just resort to drawing everything on a surface instead?
First of all you should test the interface your thinking of and see if it takes a performance hit. Having a lot of labels all loaded at once will increase your memory footprint but depending on what else is going on in the app, it might not matter.
Secondly, you can't easily reuse the labels but it is possible. However, you would have to constantly monitor the displayed area of the scrollview and move the labels frames around as the view scrolled. I doubt you could do that efficiently. It would take a lot of coding in any case.
Thirdly, any grid like layout can be easily displayed in a table without making it look like a table. For example, the photopicker layout is a table but it looks like a bunch of icons on a white background. Another app I saw used a table to display paragraphs of text but it looked like an ordinary scrolling textview. Every row in a table can be customized to display exactly what you want. In principle, you could use a different cell for every row and they could all be unique in their height and contents.
The advantage of the table is the the table manages what is and is not on screen for you. It does reuse cells and their contents which makes them more efficient. The table also makes it easier to manage a lot of data.