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.
Related
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.
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 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 want to display an animated arrow that goes back and forth (using flex 4). I'm using the following move effect :
<s:Move id="animateArrow" target="{arrow}" duration="750" repeatCount="0" repeatBehavior="reverse" yFrom="{arrow.y}" yTo="{arrow.y - 25}"/>
When needed, I then play the effect:
animateArrow.end();
animateArrow.play();
The animation works as intended but it seems to be a huge resource hog while playing. Any logic that happens while playing the animateArrow effect takes a very long time to load. Is there a better way of doing this?
Any effect will take resources. If it's taking more cpu than anticipated, you might want to look at the object you're moving, it's container, and the code it might affect.
Personally, I wouldn't use Adobe's animation library as they aren't very optimized. I would look at TweenMax instead.
IF i want to load any image quickly should i use as a css background not in ? I think difference only will show in low speed internet connection.
I saw many articles related to css only preloading they all are using images in css background.
http://perishablepress.com/press/2008/04/15/pure-css-better-image-preloading-without-javascript/
http://perishablepress.com/press/2007/07/22/css-throwdown-preload-images-without-javascript/
http://divitodesign.com/css/create-an-image-pre-loader-with-css-only/
It's all about the order in which things happen. Browsers are at liberty to begin processing things as soon as possible, so, in the average page with the css defined in the head, it is able to start requesting and recieving images from the css before it would be able to do so from the body of the document.
So in short, the answer is yes.
But... bear in mind that it doesn't actually load the images any faster. All you are doing is changing the load order, not the absolute speed. The images will still take the same amount of time to load. If you move everything out of the body and into css in the head, you are still left with priority decisions as to which ones to load first. So you come full circle. You can't make everything faser than everything else.
This is clearly browser-specific. Besides, there is no logical reason it should be the case, and wouldn't quite make a difference even on low-speed connections. Even if there was a 200 ms delay between the starting load time of an image on a page and of an image in a CSS rule, the end user would never notice it.
If you have to do a web page for low-speed connections, the solution isn't really to "optimize" that way.