I've been using latest Kendo grid for ASP.NET MVC.
Data table specs are like this,
columns --> 25 to 35.
rows --> anywhere between 1500 to 5000.
client side paging --> 20 rows
Issue is, when I'm doing the scrolling, IE 11 takes upto 1s to display data depending on screen resolution and grid content height. Which causes the UI glitch.
When I ran IE UI Responsiveness from Dev Tools, I got the below results.
I get that whenever user does scrolling, browsers have to render the rows and it takes a bit time. But IE 11 takes it to a whole new level. The moment it has to process 3-4 more rows, it starts acting jumpy and glitchy.
I did the testing in Chrome (& opera), Firefox. In which performace was very decent.
I tried to refractor CSS to reduce styling, but there's very little bit change I could afford.
Please let me know what is the next step? Should I keep calm and blame IE?
The grid works fine on its own in IE11, my team uses it.
It could be you've added some code that's being executed excessively.
The UI responsiveness tool isn't very useful. Try using the profiler in IE's Dev tools. Open the page with the problematic grid in it, hit the green arrow of the profiler to start recording, scroll the grid a bit and then hit stop in the profiler.
Sort the results by Count, Inclusive time and Exclusive time and see what stands out. After each sort look at the top ~50 entries for code you wrote.
When sorting by Count, you might find a piece of code that while is pretty short, it runs hundreds of thousands of times in a loop for no reason because of a simple mistake.
Sorting by time can show you pieces of code that are very demanding and perhaps could be moved to other places.
For instance, it could be you're running some logic on the view like formatting a date. If you see such a function in the profiler, it would be better to move this logic to the data fetching phase before the view is rendered.
There's an issue with a file named angular-material.css which causes a slow scroll like you describe. I've seen several places, like this one, that state removing the file or several lines in it solved the problem.
Are you using angular in your project? If you do, see if you have this file and try to remove it.
Because this question crossed 1000 views, I'm obliged to answer on how I fixed my issue.
Turns out, rendering of IE is slow when it comes to bigger screen of HD/FHD resolutions. So, the solution I followed was to promote the grid to new layer by adding the following to grid's CSS class.
.promote-new-layer{
transform: rotate(0deg);
will-change: transform;
}
will-change might not work in all the browsers. Hence the fallback would be to use transform:rotate(0deg).
Please ensure while doing so, you are not promoting unnecessary nodes.
Related
So I'm working on this app in electron, and I noticed when I move the app over to my second monitor it seems to lag. Curious what might be causing this- I opened up the dev console, and sure enough- my animations drop from a very comfortable 100-150 fps, to a consistent sub 50 fps. The animation is a height transition, which is poorly handled by the browser, but even this doesn't explain the massive performance drop I see by simply dragging the window over to my second monitor.
I'm considering rethinking the way I handle the animation, to mimic the current look of it using only transforms, but it would be nice to know what's causing the stuttering and lag, since the lag doesn't appear to be specific to my height transition. After digging around for a bit in search of an answer, I'm no closer to anything that might be called a solution. I'm not posting any code with this because none of the animations are handled with JS. It just plain and simple CSS- nothing crazy about it.
To me this seems like it more of an underlying issue with electron itself, or perhaps something strange the OS does.
I've inherited a css file (10k lines), which I think is responsible for an insane cycle of style invalidation, recalculation, redraw. I figured this out by removing the css file from the page, which results into the disappearance of the cycle.
The file was created over time by several people, and no one is left with a full knowledge of the css content...
From the profiling attached, there's no Network activity, or JS event that could pinpoint at another root cause (such as DOM changes using JS).
In your view, what would be the best approach to find what triggers the view changes? There's no animation on the page, but I can't guarantee that there isn't one spinning on its own using an old css directive that nobody uses anymore...
The repaint causes fairly high cpu usage.
thanks!
It might not be the best solution, but I'd remove the bottom half of the css code and check if the problem still exists.
If it is solved, you now know it is in the bottom half, if it still exists the problem is in the top half.
Keep halving the code which should contain the problem, and in about 9 iterations you can have it narrowed down to about 20 lines.
I have a really big performance issue with Internet Explorer (8 and 9) and large data tables.
When I loaded a few hundred items, the browser (not only Internet Explorer, but also Chrome and Firefox) starts lagging a lot. At first I thought it was because of JavaScript, but later I realized that it was CSS's fault. I found out that with display:none the browser does not render elements, so I made tweaks and started grouping elements in elements and hiding them when they are not visible in viewport like this:
<tbody style="display:none"></tbody>
<tbody></tbody>
Performance did really improve in Chrome and Firefox, but not in Internet Explorer. Internet Explorer seems to still be rendering or trying to recalculate styles for those hidden elements. It looks like display:none makes no difference on Internet Explorer. If I could make not rendering work I believe performance should improve, but I don't know how...
Also the reason why browsers starts lagging with large data table is because each row has about 50 elements inside which are also heavily styled with CSS.
I don't know what else to try to fix this in Internet Explorer...
Any ideas?
P.S.: table-layout is set to fixed
Rendering speed also depends on the way you create elements to the DOM, even though the script itself would be executed fast.
By my (Internet Explorer) experience document.write() is the fastest way to create large tables. It can be over 100 times faster than appendChild(document.createElement()). Also insertRow() & insertCell() are remarkable faster than creating and appending each row and cell. innerHTML seems to be the slowest method to add content (though in this case it can be used to create cell content only, not the table itself).
Unfortunately these differences between performance are not necessarily cross-browser, one browser is doing the same job faster with some other method than another browser...
What can you do then? Try to "split" your table into several smaller tables. You said that table-layout: fixed is set; do you also use COL and/or COLGROUP tags and widths for those? Without them setting table-layout is pretty much useless. Or you could use lazy loading; just load a small part of the table, and when needed, load more.
"Example": I've created an Internet Explorer application, which currently shows 379 tables having six rows with eight cells each. To create and render those tables takes less than 2 seconds (in Internet Explorer 9). However, (I just tested) if I'll create all 2274 rows to a single table, rendering will take about 15 seconds. I assume that splitting the large table to smaller parts would speed up rendering in other browsers too.
Having used display:none on elements that aren't being viewed myself, I can assure you that it is a massive performance gain, even in IE.
The problem you have here is that the browser is constantly having to recalculate column sizes, especiallywhen you change display properties.
To fix, try adding table-layout:fixed to your table's styles. This will effectively disable dynamic column widths and make for more consistent viewing when elements change. You may need to specify widths for your first row, however. This should result in an astronomical performance gain in all browsers.
In order to fix the redrawing issue, use a document fragment. Children appended to the document fragment are not rendered and will not cause the issues you see. You can then insert the fragment itself into the table:
var docFrag = document.createDocumentFragment();
// The following is pseudo code, but you get the picture
for (var i = 0; i < largeCount; i++) {
var row = createRow();
docFrag.appendChild(row);
}
// Append the fragment to the table (or even tbody)
var tbl = document.getElementById('myTbl');
tbl.appendChild(docFrag);
The document fragment itself does not render as anything, it is basically a container element that acts as a placeholder and disappears after you insert it into something.
EDIT: Further information can be found here.
It is actually an issue for all the Internet Explorer browsers without Internet Explorer 11. In general (for all other browsers) 'display:none' means that everything in it shouldn't be really processed from the browser on load, but Internet Explorer does that for some reason.
The only solution is to keep it out of the DOM and render part of the table.
I had the same problem. I initially had one table with 1000 records which was crashing most browsers (Firefox was the only one processing it). And even if it processed the initial DOM, the table was giving that slow dragging sensation (really annoying). So it was kind of unusable.
Then I divided it into smaller tables (200 records) with select drop-down and display:none from the start. This actually completely fixed the issue with the slow page dragging for all browsers. The only problem remained the slow (it takes about 2000 ms) initial load in Internet Explorer 10, 9, 8.
The only way to fix that unfortunately is to specifically exclude the tables from the DOM before load.
I can't see the example code, but you could remove the hidden elements from the DOM.
So instead of just setting display:none, detach them with removeChild() and store them in some object until you need to show them and then insert them at the appropriate place.
I am a self-taught web designer with a staggering 3 sites or so under my belt. I just finished the first page of a website for a client who is a friend and therefore a lot more patient than a "real" client would be.
I love the way the sites looks, it is fairly consistent in the spectrum of popular browsers, and overall I was quite proud of it until I realize a major problem that to be honest is about two steps away from making me drop my dream of becoming a web designer.
When using Chrome, Safari, or older versions of Explorer the website's layout falls apart if someone has their zoom set to anything other than 100%.
It is frustrating me to the point of near depression. I used a div to surround the whole body, and the pages layout, which in this case is a MENU is done almost entirely with ULs (unordered lists) positioned absolutely.
The site is made up in such a way that all the parts connect (almost like a puzzle) and if some parts are out of line, it is dreadfully obvious.
I heard the zooming rounds up figures and could call for a couple of low alpha pixels here and there, but in my case some block elements are literally 25-50 pixels out of place.
http://www.stevemarcella.com
No need to get your dreams crushed just yet :> There is always hope.
First thing you should do is check all of the errors, which according to validator are 536 errors on the homepage.
I suggest you run the validator and correct errors one by one. It could solve your problems. First error I noticed is that you have a div element outside of body. You should keep everything inside the body tags.
This is outside of body.
<div class="wrapAroundBody" id="IdWrappingWholeBody">
Hope it helps.
I'm trying to present my notecards in a web app style.
I'm not worried about caching, or making it work offline.
I just want it render well in the iOS browser.
Here's the link: http://kaninepete.com/flashcard/review.php?Sec=3
I want it to look the same as if you re-size your browser window to 320x480.
The problem is, it always renders a huge amount of blank space off to the side.
I want to lock the scrolling to only the vertical axis (like flipping through notecards),
but also have the text at a readable size.
You can use CSS media queries to set your template on a certain width/height model. This works well and can adjust specifically for iPhone screens.
As for the font size issue you'll probably need to just spend time testing. With that it's going to require some type of virtual simulator or a real iPhone where you can test the site. I just loaded it up onto my iPhone 4 and I see what you mean about additional space - this is just because of your page size. Try messing with CSS media queries I think you'll find the answer in there.
Here is a very handy Google search to hopefully get you started on the right track. CSS3 has a lot of new features. Many of them geared towards mobile :)
Reading your question again, here's some suggestions based on what I think you're looking for.
Make sure your document is valid HTML before you continue. Safari on iOS supports HTML 5, so I'd suggest targeting that, unless your platform targets something different already.
If you just want it to run well in iOS Safari, then code for that. If you want it to look similarly in other browsers, however, then it may be necessary to look at styles targeting the iOS device (via width/height). See http://davidbcalhoun.com/2010/using-mobile-specific-html-css-javascript (It seems hacky, but based on some research a week ago, this still seems to be the suggested route.)
You've got CSS that shouldn't be in there if you want to target multiple browsers. overflow:hidden and set pixel widths.
Generally, I'd say you'll want to tweak your markup as well. List items or headers would be much better than just simple breaks.
Maybe I'm just oversimplifying the question, but it looks to me like all you really need to do is wrap each notecard in a div, perhaps giving each div a <div class="notecard_wrapper">. then just attach a stylesheet that specifies the width and height you want for each card.
This page explains Safari's viewport and how to change it. It will probably fix the font size problem and maybe help with the page size.
Basically, Safari by default simulates a screen that's about 900px wide, when it's actually about 300px (so the page appears zoomed out). This makes pages designed for real computers render properly, but for a web app you usually don't want it to zoom the page at all. The viewport tag should let you control that.