looking at the resource tracking in chrome. There is a lot of purple instance called
Paint (179x40)
and then when you hover over it it says
Re-calculated style - details
Duration 0 (at 7.14s)
Used Heap size 8.77mb of 11.37mb
And there are hundreds of them. Can someone please explain?
Based on how most GUI programs work, that is the function used to redraw the screen. Any time anything changes on the screen in a GUI program, Paint() is called. I assume that Chrome is following a similar paradigm.
Related
I apologise for a slightly fuzzy question but there are no other developers in my office and I need some help from somewhere. If you can even suggest a vague topic for me to look into it would be great as I have been banging my head against this all day with zero progress.
So, I have built a little image display widget (Flash CS6, FlashPlayer 10.3, AS3).
It is simply a container clip into which I load a a stack of images (wrapped in a custom class), one on top of the other but offset a little so that the side of each is visible to be clicked.
Each of the images listens for MouseEvent.ROLL_OVER and becomes the active image when this happens, I also have a listener attached to the stage of their container clip that listens for Event.MOUSE_LEAVE and updates the display when the user is not actively engaging with the Flash area.
Everything works fine when I run within Flash and also when I test in Chrome but in FF and Safari when I mouse out of the Flash area, as well as the expected MOUSE_LEAVE, a ROLL_OVER is also registered by the very bottom image in the stack. This means that whenever you mouse out in the affected browsers the bottom image always becomes active rather than the last one you actually rolled over.
Any thoughts, even vague possibilities, would be great because I am stumped. This is either some really tiny detail of Flash event propagation that I'm not getting or some stupid mistake that I've over thought into a mountain :)
Right now I will take what-ifs, maybes, legends, riddles, anything!
Sorry again for the rather rambling explanation.
Thank you in advance for any advice.
Sometimes when I Inspect Element in Google Chrome I find that I have some large frames, but they are filled with white space. Anyone know what often causes such large amounts of empty space? I have seen timers cause issues with extending the frames length but in the example below I am unsure why a frame would be so large.
Would love some help minimizing these
This is documented here, see the 'About clear or light-gray frames' section. 'Clear frames' in question are described there as
Idle time between display refresh cycles.
According to this video, clear bar indicates browser waiting for a CPU or a GPU. There is nothing that developers can do to fix this when working on a 'standard' website.
I found some interesting relations and i hope it will save time for someone (I spent lot of time before figure out all of this)
Most important - chrome devtools cost a lot. A mean A LOT, even if it says nothing about it. For example:
"Screenshots" in performance monitor increases frametime from 16ms to 66ms in my case and just fills it with empty space in timeline - without screenshots and with screenshots. (Now i see long operations on GPU with screenshots, but there's no any info about what exactly particular operation did)
Things in "rendering" tools like "paint flashing" or "fps meter" greatly increase painting operations time. Just be sure that you disabled all of this before analyze performance!
Very strange things happens with "other" segment(Grey color on timeline). It suppose to be devtools cost itself, but sometimes it can randomly be around zero with lot of calculations or be on 100% wile idle. My advice - there's new "performance monitor" tool in new chrome versions (Not simple "performance"). It is better to toggle it on and keep an eye on "CPU usage" timeline. If you see unexpected behavior of gray curve just reload page or whole chrome - it may save lot of time for you.
Some extensions may cause random effects on timeline. It better to disable it too.
Actually any thing in tools or extensions may ruin your measuring. Toggle all of it off before start search out issues in you code, dom, or styles
I'm running a simple viewbox animation in raphael using requestAnimationFrame in chrome. I'm noticing all scripting and rendering tasks are completed yet I still see anywhere between 30 and 60ms of "dead space" where it looks like the browser is sitting there doing nothing. Any insight into this?
I went on this question looking for the same answer and as it seems nobody provided a response, here is what I found.
According to the Chrome DevTools documentation about the Clear and Light Grey Frame, the blank space is the time your browser was idle.
Why is it idle?
The short version is that a hollow frame means one of two things: your javascript main thread was busy doing other stuff that the Chrome Dev Team forgot to show in DevTools or you were bottlenecked on your GPU.
To tell the difference, you can enable "Timeline: Show CPU Activity on the Ruler" inside DevTools' settings (you know, the cog in the bottom right hand corner).
You will end with something like this:
See the little dark grey blocks on the "Records" row? Those are dark when the renderer thread was busy. If the renderer thread is mostly idle, e.g. no dark block, as is the case the screenshot I yanked for this post, it is a very good signal that you are GPU bound.
Here's the full explanation from Chrome Engineer Nat Duca.
https://plus.google.com/+NatDuca/posts/BvMgvdnBvaQ
I have a page that has pretty heavy (mid-weight rather) canvas operations going on. To cater for users on mobile devices and older computers I was thinking I could implement a mechanism that will check if the canvas element is actually visible and decide if the constant calculations and canvas updates (animation running at 30fps) do have to be done or not.
This is working fine, yet when doing a performance test with the Chrome Dev Tools I noticed that even when I disable my visibility check and just let things render all the time the CPU usage of the function in question drops quite a bit when no part of the canvas element(s) is visible (although in theory it should still be performing the same tasks). So: at least on my computer running Chrome 17 it does not make a real difference if I check for the element's actual visibility.
To cut a long story short: Do I need to do this or are browsers smart enough to handle such a case without even telling them (and I can save the visibility checking)?
EDIT:
So I made some "research" on this topic and built this fiddle.
What happens is that it just generates noise at 30 frames per second. Not too pleasing to the eye but, well... The upper part is just a plain div to block the viewport. When I scroll down and have the canvas element in the viewport CPU Usage tells me it's taking up about 40%, so apparently the browser does have quite a lot to do here. When I scroll back up so that I just have the maroon colored div in my viewport and profile the CPU usage it drops to sth around 10%. When I scroll back down: usage goes up again.
So when I implement a visibility check like in this modified fiddle, I do see an increase (a tiny one to be honest) in CPU usage instead of a drop (as it has the additional task of checking if the canvas is inside the viewport).
So I am still wondering if this is some side effect of something that I am not aware of (or I am making some major mistake when profiling) or if I can expect browsers to be smart enough to handle such situations?
If anyone could shed a light on that I'd be very thankful!
I think you're confused between whether the logic is running and whether the rendering is happening. Many browsers now hardware-accelerate their canvases so all rendering happens on the GPU, so actual pixel pushing takes no CPU time anyway. However your tick function has non-trivial code to generate random noise on the CPU. So you're only really concerned over whether the tick function is running. If the canvas is offscreen, it certainly won't be rendered to the display (it's not visible). As for the canvas draw calls, it probably depends on the browser. It could render all draw calls to an off-screen canvas in case you suddenly scroll it back in to view, or it could just queue up all the draw calls and not actually do anything with them until you scroll the canvas in to view. I'm not sure what each browser does there.
However, you shouldn't use setInterval or setTimeout for animating Canvas. Use the new requestAnimationFrame API. Browsers don't know what you do in a timer call so will always call the timer. requestAnimationFrame on the other hand is designed specifically for visual things, so the browser has the opportunity to not call the tick function, or to reduce the rate it's called at, if the canvas or page is not visible.
As for how browsers actually handle it, I'm not sure. However, you should definitely prefer it since future browsers may be able to better optimise requestAnimationFrame in ways they cannot optimise setInterval or setTimeout. I think modern browsers also reduce the ordinary timers to 1 Hz if the page is not visible, but it's definitely much easier for the browser to optimise requestAnimationFrame, plus some browsers get you V-syncing and other niceness with it.
So I'm not certain requestAnimationFrame will mean your tick function is not called if the canvas is scrolled out of view. So I'd recommend using both requestAnimationFrame and the existing visibility check. That should guarantee you the most efficient rendering.
From my own experience it renders whatever you tell it to render regardless of position on screen.
An example is if you draw tiles, that exceeds the canvas size, you will still see the performance drop unless you optimize the script.
Try your function with a performance demanding animation, and see if you still get the same results.
I have a flex/actionscript based project. The project has various view stacks and tab navigators and a few popup windows. The whole thing is managed in pureMVC framework.
When transitioning between various view states, opening a popup, switching a tab, etc, I find the app to exhibit various redraw glitches. Parts of views will be partially drawn or flicker in odd ways. I am fairly confident that the code is working correctly, just seems to be an issue with the overall heaviness of the UI.
Is this a common issue? Are their tried and true techniques to optimize this problem?
In particular what event handlers are available to delay the drawing of view components until the last moment when everything is ready to quickly display to the screen?
Say for example I have a VBox inside a viewstack, and inside this VBox I have a fairly complex datagrid. Can I prepare the datagrid and/or delay the viewstack change until all subview components are in fact ready to be quickly drawn.
What are some possible symptoms to this kind of glitchiness?
just a guess, but this might be related to the flex framework ... i experienced this kind of behaviour too ... i guess it is related to the way flex framework works when carrying out ui tasks ... a lot of deferred instantiations/calls and so on ... when there is a lot going on, the framerate drops and since deferring is framebased, that is probably when the resulting delays become noticable ...
greetz
back2dos
Not sure if this applies to you, but in Firefox/OSX there is a known bug when you make too many javascript calls, and the result is similar as you say... the whole interface shows various glitches and flickers... The solution was to delay the JS calls a bit, so they don't get called too often... this was a serious issue with swfaddress for instance (I think it still is).
http://www.bigspaceship.com/blog/labs/mac-firefox-30-flash-javascript-random-artifacts/
I assume you need the datagrid already attached to its parent container and you are loading data while it's being shown so it constantly updates and renders its content.
Have you simply tried setting its visibility to false until everything is loaded while keeping includeInLayout true and giving it a fixed size?