Grid slow when set visible to true

Vaadin 6 / 7 / 8 Framework UI
1

I can hide a grid with grid.setVisible(false); and it is quick, but when I try to show it again, using grid.setVisible(true);, it is slow to load. If I enable exta columns, it is even slower. For Table, it was always instantaneous to show or hide the table. So why is Grid slow to paint the screen when I make it visible again?

When I look at the HTML, to me it looks like Vaadin treats setVisible(true); and setVisible(false); do the same thing with both Grid and Table, at least conceptually. If I watch closely in the browser inspection, I see the HTML being added back, but there is a delay before it sets style="height: 93.3333%;". In other words, when I show the grid again, for a second the HTML is <div class="v-slot"></div>, then it fills the div with data and sets the height.

Vaadin: 7.7.13

Test Browser: Chrome or chrome based browsers (have not tried IE yet)

2

I just tried the final release for Vaadin 7, 7.7.17 (https://github.com/vaadin/framework/releases/tag/7.7.17), and it is slightly. We currently have a Pro license, so I cannot find the latest release ([7.7.22]
(https://github.com/vaadin/framework/releases/tag/7.7.22)), but looking at the release notes between 7.7.18 and 7.7.22, I don’t see anything that suggests a performance enhancement for Grid anyway. So any ideas on what to do to improve things further would be much appreciated - it is noticeably slower then the same action for Table.

3

Instead of using setVisible(true / false), you can hide the Grid with CSS. It’s less efficient memory-wise, but you will not need to spend so much time rerendering the Grid.

4

Sounds good. Two follow-up questions:

  1. Is this fixed in Vaadin 14?
  2. You say it is not efficient memory-wise to use CSS, but why? It has to be more memory intensive on the server, since Vaadin is obviously doing something extra that table was not doing to rerender the Grid, which means that should be less efficient memory-wise to do it without CSS.
5
  1. It’s a completely different client side implementation.
  2. setVisible(false) removes a component from the DOM tree → less memory needed to maintain the nodes in the browser
6

Thanks. I tried the following:

	@Override
	public void setVisible(boolean visible) {
		this.visible = visible;
		
		if(visible)
			removeStyleName("hideGrid");
		else
			addStyleName("hideGrid");
	}

with the following CSS:

  .hideGrid {
  	display: none;
  }

It hides just fine, but when I set it back to visible, it does not change the screen much, the grid is still hidden. What am I doing wrong?

Total side note: eventhough I am overriding the “setVisible” in my Grid implementation to NOT doing the normal Grid.setVisible actions, it still removes the DOM element (v-slot that contains the grid), and then adds the DOM element back when I set it to visible. Not sure why that happens, but it seems quicker (eventhough I cannot see the actual grid).

7

Not really sure what I am doing wrong with CSS, but something else occurred to me: I am using renderers with every single column, even text columns. I seem to remember reading someplace a potential performance hit for using renderers. I have to use renderers sometimes, of course, for dates and doubles (for instance), but would it help if I got rid of TextRenderer references that I don’t require?

8

I can’t see the cause, but I would at least not override setVisible for that purpose - it has its own semantic meaning, and overriding that would be confusing for any third party looking at the code.

If I recall correctly how it works, TextRenderer should be the default Renderer used anyway, so getting rid of those might not change anything. Worth a quick try, though.

9

Ok, the key was not overriding setVisible. I guess something somewhere sees the old definition of setVisible and removes data from the DOM. Once I did as you suggested, it worked perfectly. Thanks.

Incidentally, about TextRenderer, I think you are right. I tried it and I noticed no difference at all, and digging into libraries proved your theory that TextRenderer is default renderer (in Column constructor).

10

Ok, I was slightly wrong. It seems even using pure CSS, it still removes things from DOM. It keeps the v-slot DIV there just fine, adding hideGrid class, which is why I missed it. That said, for some reason it removes most of the data TR html elements (it seems to keep the first TR for the TBODY element, removing the rest). It is very slightly better, sometimes, but it is not consistent. Maybe this will be good enough for the users, just don’t understand why such a common behavior is so inefficient.

I hope Vaadin 14 does not have the same problem, since it is a total redesign, but have not had a chance to confirm.

11

One thing that you can do, if you want to speed up the rendering of Grid: use fixed column widths. By far the most time that’s needed goes to recalculations of column widths when new information appears. There are some optimizations done in Grid column calculation in Vaadin 8, but how much they help can be pretty situational.