chrome devtools
Hello,
What is Composite layers in chrome devtools?
I want an animation (using canvas) to be as fast frame rate-wise as I can get it, and it seems like all function calls take about .78 ms
But after the draw functions have been completed the task seems to go on for a few ms to at the end do "Composite layers"
What is composite layers and is there a way to get rid of it and/or optimize it to save some time?
I have tried doing some research on what this is, but I can't seem to find anything that helps me.
Related
A few days ago, I was wondering about why my canvas is not working properly. I'm using szimek's library to create signatures and sometimes those pen strokes looked a bit crazy. I also tested on Edge (which ended in the same result as Chrome) and TOR (worked as it should).
Yesterday, I found the solution why this happens randomly. My strokes look crazy during the usage of the browsers developer console when it's open. If it's closed, they're looking normally (when drawing again).
Does anyone know why this happened or is it caused by it's core engines?
Here's an example of what I mean:
Thank you.
This happens because in Chromium (and in Gecko), as per specs recommendations, UI events like mousemove or pointermove are throttled to the frame refresh rate of the monitor.
However, in Chromium only and for whatever reason, when the dev tools are open, they emit the raw events...
So when dev tools are closed, even though the hardware pointer (e.g mouse) did emit more events, these have been coalesced into a single pointermove event, which may draw lines smoother to the eye since each point have been averaged, but you actually received less data.
You can retrieve the list of raw events from the pointermove event's getCoallescedEvents, as exposed in this other answer of mine, and from these you could also build up the coalescing logic yourself if needed (using requestAnimationFrame() as a throttler, that's exactly what Chromium does).
As to why Chromium does disable the coalescing when dev-tools are open... that's still a mystery for me, but I never got enough incentive to look this up.
I'm measuring performance via Chrome's DevTools on a web app that puts anywhere from one point to thousands of points on a Google map (mostly custom markers). The issue is that I cannot tell if Chrome's DevTools has "stopped responding" (in quotes because it's not actually non-responsive, but the performance being measured seems to flat-line), or it's pointing to a code problem.
To reproduce, I start the performance recording, turn on the markers (again, can range anywhere from 1 to thousands), zoom / pan around the map, sit idle for a few seconds, stop the recording. Here is a typical result:
As you can see in the image, at some point the CPU meter quickly climbs to and stays at 100%, Frames are no longer measured, function calls seemingly never finish, JS Heap and Node readings flat-line (the function call that supposedly never finishes this time is pointing to google's common.js - however, it's almost always different with every reading...sometimes it's our own files, other times it's jQuery.min, etc - I do not think think this is a Google or jQuery problem).
What is DevTools telling me - that it's performance is no longer accurately being measured, or that the code is wrecking havoc on the CPU and memory?
If you notice, "Interactions" are still being captured (ex - mouse move, scrolls, etc), so this is leading me to believe that DevTools is still recording, but I'm unsure if the "CPU" and "Main" readings are accurate.
Local setup:
Windows 10 pro (64-bit)
16gb ram
8 core
1TB SSDHD
Front-end setup:
Google Maps (v3)
Front End (Angular / Jquery / Javascript)
Chrome Version 61.0.3163.91 (Official Build) (64-bit)
I had a hard time figuring a proper title for this question..
I am loading PNG files from external URL, but with one particular PNG, no-power-of-two, alpha-chanel, created with gimp, when I loaded and use as texture in a plane, It renders mixed with what it looks like screenshots portions of the current screen. in the attached screenshot you will see that it looks like if the cat had a layer on top with inverted parts of the chromium developer inspector window, that is opened at the right.
I notice that it says that as the image is not power of two, has to be resized, but I had not noticed that behavior with other textures.
using three.js R77, Chromium Version 57.0.2987.98 Built on Ubuntu , running on Ubuntu 16.04 (64-bit)
Yikes, that's a bug in the browser. Could you please post a self-contained sample showing the problem? If it's not too much trouble please create a bug on crbug.com/ and attach it, but otherwise please just put the test case somewhere and send me a link. Thanks. (I work on Chrome's WebGL implementation.)
I'm trying to optimize the Javascript in our browser app to make sure that animations always run at 60fps. I'm using the Chrome (57) Timeline tool analyse bottlenecks. Many are well solvable, but I also encounter a few very mysterious phenomena:
The screen shot below shows an empty timeline (during a long running CSS transformation), but still the frame exceeds 16ms. Where do I find what is going on there?
The other weird phenomenon is shown below, where part of a function's logic has been moved into a requestAnimationFrame() statement. That logic is nicely moved along further in time, still it seems to stretch the whole frame to 21.3ms. Why is that happening?
I hope someone can shed some light on these cases.
Thanks!
Pascal
I am trying to render as much triangles as possible in webgl. Everything works pretty well with all webbrowser except with chrome. After 57000 triangles I get a blank canevas. So I check the chrome task manager and I saw that the GPU takes 2 700 000ko before this blank screen. Is it possible that the problem come from this ? Here the code : http://gogotriangl.orionhub.org:8000/triangles/ch04-05_BlueTriangles.html
You are creating too many buffers. Get the webGL inspector, and running your app for a few seconds and I see you already created over 1.6k glBuffers:
But when you are drawing, you are only using the most recent:
Either re-use the glBuffers with gl.BufferSubData or delete the previous glBuffers via gl.deleteBuffer.