The trace shows that SingleThreadTaskGraphRunner::RunTaskWithLockAcquired is running for ~90 ms at a time without actually doing any work that's quite odd since this is a very simple functions. Two options come to mind to investigate this further:

1) Record another trace with *all* categories enabled. For best results do this with as few tabs open as possible (but enough tabs open to reproduce the problem.
2) Or, grab an ETW trace using UIforETW. Instructions are at https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/. These traces can be longer so it may need to be shared on Google drive or similar.

Either way the trace doesn't need to be long, just long enough to reproduce the sluggishness. If you can explain what you were doing while recording the trace that would be helpful. Something like: "Started tracing, dragged the scrollbar on slashdot.org down for about two seconds. Scrolling was extremely chunky. Stopped tracing." - understanding what the trace represents can make analysis easier and less error prone.

Thank you for reporting this issue. You can remove the "Needs-Feedback" label when you've gotten either another chrome://tracing trace of an ETW trace (which I suspect may be more useful).

Thanks for investigating! 
So I created another trace file, while recording this trace I was doing the following actions:
1. initial state: the browser was opened with only one tab open (chrome://tracing)
2. stated recording
3. opened a new tab (with the '+' button on the top) => this action was taking long then usual
4. type in google.com and enter
5. google.com site was loaded fast as expected 
6. close google.com tab with the 'x' button on the top of the tab (this action also took too long)
7. created new tab with the '+' button (this action took too long)
8. switched to the first tab (chrome://tracing) (this action took too long)
9. resize the window from full screen to window (this action took too long)
10. resize the window again to full screen (this action took too long)
11. closed the new tab from step 7 with the 'x' button (this action took too long)
12. stopped recording

Thank you for providing more feedback. Adding requester "brucedawson@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

It looks like you forgot to share the trace that you recorded.

Also, for a problem like this I suspect that less-is-more. You could probably stopped after step 6 in your list of steps, to keep the trace small. And, you don't mention it so don't forget to enable all categories, to improve our odds of understanding what is going on.

If you want to do all the steps (it's not a bad idea) then maybe record two traces - one that stops after step 6, and another that goes all the way.

sorry for missing the file on the last comment and also for being super late.. we had some holidays and I had no time to deal with it...
anyway i cut the trace into two:
first file named short is doing the script from last comment up until level 6 (where you suggested to stop)
and the second file named long is the whole script from level 1 to 12.

thanks a lot! 

Deleted: trace_long.json.gz 5.0 MB

trace_long.json.gz 5.0 MB Download

Deleted: trace_short.json.gz 3.3 MB

trace_short.json.gz 3.3 MB Download

Thank you for providing more feedback. Adding requester "brucedawson@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks! I just looked at the short trace since that seemed to have enough information, for now anyway. It shows heavy CPU usage from just after 1,800 ms to just before 3,800 ms, so almost two seconds. It looks like this excessive CPU time is correlated with CompositorTileWorker1/11012 in the browser process, doing things like OneCopyRasterBuffer::Playback. One of these calls takes ~183 ms (the target for an entire frame is < 16 ms) and, judging by the v-blank data, it looks like one frame ends up taking over a second.

The full task stack is SingleThreadTaskGraphRunner::RunTaskWithLockAcquired calls RasterizerTaskImpl::RunOnWorkerThread which calls RasterTask which calls OneCopyRasterBuffer::Playback - so, the results are consistent with the previous trace (which just showed SingleThreadTaskGraphRunner::RunTaskWithLockAcquired because not enough categories were enabled)

The GPU process looks mostly idle during this time. It is in some pretty long calls to GLES2DecoderImpl::DoLinkProgram but "pretty long" in this context ~18 ms, so it's not clear that this is really the issue. Shader compilation is known to take a while, especially early during program execution, so this may be "normal and expected".

Ultimately execution in OneCopyRasterBuffer::Playback goes down to OneCopyRasterBuffer::Playback and various child functions that are not instrumented. I can ask the rendering experts if they know anything about this but I suspect that an ETW trace would also be very helpful. If you can grab an ETW trace - with the GPU tracing checkbox checked - using the instructions at https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/ then I think that would be very helpful.

This ultimately may be a GPU driver problem so you should make sure that your drivers are up-to-date. It could also be a CPU/GPU overheating problem so using Intel Power Gadget or similar to monitor your CPU temperature could be useful. But, these are just speculation. An ETW trace is likely to reveal the truth.

The ~two seconds of heavy CPU usage seemed to be caused by opening the new tab (it started about 300 ms before the new tab opened). Next time maybe shorten the scenario even more and just record opening a new tab.

Can you get an ETW trace (see previous comment)? Perhaps check your drivers and CPU/GPU temperatures as well, but mostly I think we need an ETW trace o understand what is going on.

sorry, but i gave up and re-installed windows with full disk format and now everything is back to normal...
thanks a lot for your time and patient 

Thank you for providing more feedback. Adding requester "brucedawson@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm glad things are back to normal. I guess we'll never know what was wrong, but presumably some Windows/graphics issue. I will close as WontFix.