Those who have experienced a violation as forced redraw when executing a JavaScript script in the DOM?

There is a table in the style of the CSS grid styles. Which has 12 columns. Of them on the screen only 11 and 12-I am hidden to the left beyond the monitor as an additional menu for the line (applications). Just 100vw (which can be seen immediately) plus 100vw (à La carte) minus 1 column (type of application). I.e. if one says, roughly, that 100% + 100% - 40px. But the screen only shows 100% and the rest is cleverly hidden by using overflow-x: hidden, so nothing gets out.
According to the author, when the desktop resolution has to be emulated to something like a swipe on the mobile, at the moment when the user pulls the block type of the application from left to right and, in the case of closure and Vice versa - from right to left.
In the implementation there is a problem in that there is a record of the violation:
[Violation] Forced reflow while executing JavaScript took ..ms

In dynamics, the user can add as many lines (selection and screening of applications). The more rows, the more increases the time for the forced repaint to DOM elements.


[Violation] 'mousemove' handler took 442ms
[Violation] Forced reflow while executing JavaScript took 439ms
[Violation] 'mousemove' handler took 1520ms


5e29ac4732a18046578338.png
5e29acb104635764252924.png

Example:
CodePen

Help to understand why this is so.
April 4th 20 at 13:31
1 answer
April 4th 20 at 13:33
Answering the question "why is this happening?": because you have implemented a fairly complex grid with complex conditions, to the elements which you have to dynamically apply some custom styles (specifically talking about the shift), forcing the engine to redraw everything - like elements after the target and. The decision not to use grid (don't know if this is an adequate solution), or (I think more appropriate) to implement the shift as something different. For example to group the cells into rows, and move these rows, simultaneously without affecting other elements; it will completely solve the problem of total redraw.

You can still try to optimize existing code, because it's a lot more, but in fact it will not solve the problem.
Thanks for the reply, will think how to optimize performance. - devyn.Larson commented on April 4th 20 at 13:36
Still, I can not understand, it does not redraw everything, as You wrote, but only what he pointed out, that can be seen in the console tab elements...
Logically, if this is due to the displacement of the elements in the document, we have a lot of lines on the page, we change the PREV/last, why should all rearranged, we're top of the line not affected?
The time delay will be approximately the same for equal length lines per page. And no matter where swiping, top (1st application) or bottom (last request). With 100 lines of warnings there, and at 1000 you receive!
Even if f-tion-handler to write code ultralight, for example, hiding an element with type application :
clickSub async function(e) {
e.preventDefault();
$(this).hide(50);
 }

the output at lower volumes (up to 100 rows per page) no violation-warning will not, but if the number of rows increase to the right (for 1000 rows on the page), the console will fall warning redraw. I.e. the more rows, the more the delay?
And the more I use, the more delay? For example, one item and + 5-th neighboring'm going to hide?
Maybe it's dependent on downloadable memory? Maybe somewhere, something to increase, if possible?
Summary. Had the impression that the more output lines on the page, the more time delay.
But, damn, 1000 lines is a lot on the page? - devyn.Larson commented on April 4th 20 at 13:39
@devyn.Larson, "we change the PREV/last, why should all rearranged, we're top of the line not affected?" because you have a grid consists of a heap of small items, which besides that it is necessary to arrange in a line also it is necessary to calculate the measures. I can not fully answer this question just because I'm too lazy to spend time searching for specific reasons. I think at your level of understanding is sufficient to accept the fact that it is not necessary to use a grid as it is you have done in the example. I even rewrote it, just for fun. It's not very much time it will take.

"I.e. the more rows, the more delay?" - well, Yes, it's logical. About Tom's speech: you have a grid made so that he has to count all all all.

"But, damn, 1000 lines is a lot on the page?" - what do you want to hear in response? 1000 lines of text - no; 1000 rows download a variety of scripts - Yes. As you can see, in fact it turns out that you have a grid running so crappy, that 1000 is still really a lot - Alan_Raynor98 commented on April 4th 20 at 13:42
In Grid structure there is nothing difficult.
/* Variables */
 --typeColumn: 40px; /* Column type of the application */
 --action1: calc(100vw - var(--typeColumn)); /* Side left frame for further action on the application*/

 .wrapper {
 display: grid;
 position: relative;
 left: calc(0px - var(--action1));
 grid-template-columns: var(--action1) var(--typeColumn) 56px 60px 60px 200px 90px repeat(4, minmax(1%, 35%)) 40px;
 grid-auto-rows: unset;
 width: calc(100vw + var(--action1));
 }


What about the small elements You mentioned? 12 blocks in the row and everything! After going 12 blocks (next line), etc.
Ie when you build any grid, if the user does not animate (say, hiding) one element (unit) in the structure, the entire grid will be redrawn? I will not argue, I'm not sure, but something tells me that is nonsense... - devyn.Larson commented on April 4th 20 at 13:45
@devyn.Larson, "In Grid structure there is nothing difficult." yeah, nothing complicated except for the part of code which you gave a lot of calculations, complex patterns with a mandatory resolution of the variables, relative values. Plus adaptiv and is itself a complex structure. And animation on top of a cast iron anvil falls on it all.

"What about the smaller elements You mentioned? 12 blocks in the row and everything! After going 12 blocks (next line), etc." - you have a grid consists of a heap of small elements. I've done a couple of thousand blocks and all began to slow down,

"when constructing any grid, if the user does not animate (say, hiding) one element (unit) in the structure, the entire grid will be redrawn?" - of course not. It is specifically in your case the grid is organized so bad that he has to redraw. I also will not argue, I just showed the obvious bottlenecks. Group line, this will solve the problem. - Alan_Raynor98 commented on April 4th 20 at 13:48
@Alan_Raynor98,
Well, below is a link to the statics in the test domain:
Example
1. html code on 1000 rows to 11 rows (removed the first row, fuck it, nothing to hide will not);
2. css code:
@media screen {
 * {
 font-family: 'Podkova', serif;
 font-size: 14px;
 margin: 0;
 padding: 0;
}
}

/* styles for desktops and laptops */
@media only screen and (min-width: 1080px) {

 .wrapper {
 display: grid;
 grid-template-columns: repeat(11, 1fr);
 background-color: #fff;
 border-right: 1px solid #e8e9eb; /* Line right */
 border-bottom: 1px dotted #e8e9eb; /* Line below the text */
 word-wrap: break-word; /* word wrap */ 
}

 .box {
 padding: 4px;
 color: #425b71;
 border-right: 1px solid #e8e9eb; /* Line right */
 border-bottom: 1px dotted #e8e9eb; /* Line below the text */
 word-wrap: break-word; /* word wrap */ 
}

 .box:nth-child(-n+11) {
 background-color: #1cc58ebd;
 color: #fff;
 font-weight: bold;
 border-right: 1px solid #fff;
 position: sticky;
 top: 0;
}
}

Think simple, no piling, no! Styles

3. JS code (easiest), when you click on the concealed type of the neighboring element:
$('body').on("click", ".j", function(e) {
e.preventDefault();
$(this).next().hide(50);
 });


a lot of calculations, complex patterns with a mandatory resolution of the variables, relative values ... And animation on top of a cast iron anvil falls on it all...
It is specifically in your case the grid is organized so bad that he has to redraw.


So what kind of calculations are we talking? Complex template with variables? Complex animation? In what particular case? How bad?
In my opinion, there's nowhere easier!
And....
[Violation] Forced reflow while executing JavaScript took ...ms
- devyn.Larson commented on April 4th 20 at 13:51
@devyn.Larson, Yes, now everything is quite simple, low logic. But the essence does not change - on click you hide the grid cell, as well as from changes in one part of the grid can vary in a different part (no matter in what place of the grid changes), then to recalculate the grid have.

In your situation, the grid does not need, is too complex a tool to solve your problem. In any case, no matter how cool the tool you use to organize a huge table from adequately long sequences of elements in itself is a stupid idea. Try at least to group the cells into rows. - Alan_Raynor98 commented on April 4th 20 at 13:54
@Alan_Raynor98,
If they are grouped in rows, each row will be evaluated/displayed independently from each other. The column may not be aligned with the column above due to the different amount of content. The way it happens. And if you try to use display: contents;
if you convert to native code and register them as sub-elements? Then direct children will be part of a mesh or flexible layout.
The article on this subject.
As far as I know, not all browsers support design display: subgrid;
Try to rewrite the code, maybe that'll help. - devyn.Larson commented on April 4th 20 at 13:57
@Alan_Raynor98decided the question simply, without any display: contents.
Broke on the line:
/* styles for desktops and laptops */
@media only screen and (min-width: 1080px) {

 .wrapper > div {
 display: grid;
 grid-template-columns: 100px 40px repeat(8, 1fr) 40px;
 grid-template-rows: unset;
 border-bottom: 1px solid #e8e9eb; /* Line below the text */
 word-wrap: break-word; /* word wrap */
 column-gap: 10px;
}

 .wrapper > div:first-child {
 background: #1cc58e;
 color: #fff;
 height: 30px;
 position: sticky;
top:0px;
 } 

 .wrapper > div:not(:first-child):nth-child(odd) {
 background: #dedede;
}

}

At first I thought that the vertical alignment on the columns will not be, but it turned out all right! Columns smooth.
It turns out that when any change in the grid mesh, the entire structure is redrawn! The larger the grid, the correspondingly worse. Hence the delay in large volumes. but if each row (block) to specify your grid, the problem disappears! Now at least 1000 rows, at least 20 000, all without delay. - devyn.Larson commented on April 4th 20 at 14:00

Find more questions by tags jQueryHTMLCSS Grid