Animal wrote: ↑Fri Jul 02, 2021 10:58 amThat wouldn't be so bad if your server returned HTTP 304 "Not modified" responses when the images are requested multiple times as you scroll up and down.
But each full sized image is served every time. Using the network tab and sorting by request size, here are some of the images and how long they take to load:
Hmm strange it loads from cache for me, but thanks for the tips, I could certainly optimize it better, I'll make a few improvements next time.
Animal wrote: ↑Fri Jul 02, 2021 1:20 pmAnd I think you misunderstand the loading of data into records as contrasted with the loading of HTML content
When loading records into a store, you just pass data. Not HTML which will end up being displayed in a data cell. The Column renderer is responsible for wrapping data up in HTML to make it look right.
Yeah I understand, I display html sometimes for a cell because that is how it was before I replaced it with Bryntum grid. I'm lazy and I only have so much time for my gaming website 
saki wrote: ↑Tue Jun 29, 2021 2:34 pmThe issue is most likely caused by fixed height of the grid container (90vh). This can do no good as we cannot say that the very inner container should always have 90% of viewport. I'd suggest to use 100vh on body, display:flex on on others either with fixed height for menu and search-bar or flex set to 1 for grid.
Also, the element's (div) container chain seems to be too deep. This fact is not by itself not a cause of rendering problems but it is more work to address all elements in the containment chain with the proper css for the desired layout.
The good inspiration for simple yet flexible containers is our demo: https://bryntum.com/examples/grid/basic/. It only contains one container, one header and one grid so it's very easy to address with css.
I don't think the problem is that some records are not loaded. It can be easily checked by typing
I replaced the divs and the 90vh with flexbox. No difference. its not the record loading I checked that.
https://www.dndcombat.com/dndcombat/Welcome.do?section=Compendium
The curious part is that if you scroll to the bottom, see the blank area, press the Reload icon, it is fine thereafter.
The rows that are missing appear to have a translate value that puts them behind the header section, as if it is calculating the y value on the page as if there wasn't a header or something like that.
You can see it here:
FYI the way I work around this on client websites is to call a second ajax load and refresh rows on the table when the page is loaded. Not ideal obviously but after that it works ok.
Your perf problem is due to using Column's autoHeight
https://www.bryntum.com/docs/grid/#Grid/column/Column#config-autoHeight
NOTE: Enabling this config comes with a pretty big performance hit. To maintain good performance, we recommend not using it.
Just make those cells default to a little wider. Do not use text wrapping, otherwise every cell needs to be measured which means the picture below. Thousands of synchronous style recalculations and layouts:
Yeah but I don't care about performance, this is just an example, the issue happens on smaller grids with no html and little data. Its caused by for some reason the row translate starting top position is miscalculated to be the top of the page instead of where it should be. Pressing the reload button manually or through code fixes it but having to load every grid twice is bad.
Removing the auto height is not an option, I don't need it in the example but I need it on my clients website.
So the issue doesn't happen at https://www.dndcombat.com/dndcombat/Welcome.do?call=JS&actionRefId=241&activeInd=1 ?
Only on other grids? I suspect it's your layout. The grid has to be sized in height by connecting layouts all the way down. I suspect that other elements are scrolling.
