Unfortunately the background images are not repeated in each cell, and I have multiple instances of different images positioned throughout each row...
For now removing the empty spans and replacing them with img tags has fixed the problem. I've refreshed the screen over 3,000 times and each...
It's set to "automatically."
So I removed the empty spans with background images, and replaced them with regular img tags. This seems to have solved the problem! Not sure why the row showing code would have affected this, but clearly the two cannot play nice together.
I've got one more test...
10 full refreshes with the display code is still faster than regular, even if it does start creeping.
I've narrowed it down to something that may make more sense.
In numerous cells within the table, I have spans with classes applied to them. These classes are in an external .css file that is...
I have not tried that yet, but it would defeat the purpose of what I'm trying to do, which is get limited content up on the screen quickly.
Yesterday I was able to (I think) isolate the problem to a specific column within the table. I just started collapsing columns, and after a certain group...
Nope, no libraries...
I created a stripped-down version of the page with limited stylesheet information but kept the same rows and row expansion code, and now it does not appear to be slowing down... But I will need to run the test for another hour or so to be sure. So the expansion function...
.rows in .childNodes didn't change anything. It's still trending up 1/100th of a second per load. I know that doesn't really seem like an issue, but this screen is the main screen for the app and is hit constantly. Many clients just leave it displaying on one system, refreshing at least...
Initially rows 16-n are set to display:none; This came as a big surprise to me, but setting them to display:none initially and then setting them to display:table-row through this function actually renders the page faster. At least in IE. If the widths of all columns could be known to me, I'd...
I should also note that this slowdown is instance-specific. Meaning if you leave the page and come back, the trend continues. Even if you leave the domain. It does not get back to its initial loading speed until you close IE and reopen it.
Well technically not a leak, since memory usage never goes up... But I've got a small piece of code that iterates through table rows #16-n (where n is the number of rows in a table) and changes their display style from "none" to "table-row." Seems simple enough, right? But after refreshing...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.