I tried to reproduce this:
http://jsbin.com/wufokarahi/1/edit?html,css,js,output

Click "Run with JS" button on the rightmost pane, and then
click on "blur" button (therealjohnparsons@ correct me if I'm doing wrong).

I'm on Linux 55.0.2883.75 (Official Build) (64-bit), and it works okay.
Will check on OSX next.

I cannot reproduce it with the URL above with 55.0.2883.87 (64-bit) on OSX.

therealjohnparsons@, could you check the jsbin link above if you still see the same
issue?

Tested this issue on Mac OS 10.12 using chrome latest stable M55-55.0.2883.83 by following test case provided in the comment #4. 

1. Navigated to http://jsbin.com/wufokarahi/1/edit?html,css,js,output
2. Clicked on Run with JS and clicked on Blur button
3. Observed the blurred image rendered clearly as expected.

Thanks!

Deleted: Screen Shot 2016-12-12 at 12.27.53 PM.png 529 KB

	Screen Shot 2016-12-12 at 12.27.53 PM.png 529 KB View Download

Unable to repro on Linux 55 & 56. Still waiting on confirmation of test case.


From the original report it sounds like a painting error (image disappearing, only redrawing on resize). Passing over to paint.

Turns out it's dependant upon the dimensions. Works find in the test page with dimensions, so I pasted the code into a blank document. Breaks approximately when window dimensions > 700 px wide. Severity increases with larger window sizes. Maybe due to hardware acceleration or lack thereof.

Added test file.

Deleted: test.html 675 bytes

test.html 675 bytes View Download

I still can't repro using the test case on Mac or Linux with M55 or M57.

I do see one artifact when the page is wide but not high and there are vertical scrollbars. In that case, the blur seems to be chopped off at the top of the screen (where it is clipped to the viewport) during the transition and then goes all the way to the top when it's finished. That is, during the transition we are not using pixels outside the viewport for the blur, then we are when the transition ends.

That may be a milder form of your issue, just maybe. Is the problem influenced by scrollbars? If so, can you try the various Mac System Scrollbar Preferences to see if they matter (I doubt it but they might).

Tried with automatic, when scrolling & always. No difference. After scrolling to move the image into frame everything outside the view slides in with the blur applied as expected. Also tried changing the ease duration to 1s, image disappears for about 2s then pops on the screen. With the simple test page it eventually always renders on my system, too. With a slightly more complex layout entailing a few other divs floating on top of this one so it's stacked 3 deep in places the image never returned in a large size window.

I know we're asking a lot of questions, but unfortunately we have no other option because we can't fix it if we can't reproduce it (except by getting lucky).

Do you have another machine you can try it on?

Can you tell us exactly what machine you are running on? And go to chrome://gpu and paste a copy of the output here.

I understand the need for questions. I'm working remotely here but trying
to be responsive on this end. Only have access to one system at this
location and time, an older MacBook Pro, the pages used to work perfectly
on it. Of course, I started working on site right after the Chrome 55
update to do the demos. :P

Graphics Feature Status

   - Canvas: Hardware accelerated
   - Flash: Hardware accelerated
   - Flash Stage3D: Hardware accelerated
   - Flash Stage3D Baseline profile: Hardware accelerated
   - Compositing: Hardware accelerated
   - Multiple Raster Threads: Disabled
   - Native GpuMemoryBuffers: Hardware accelerated
   - Rasterization: Software only, hardware acceleration unavailable
   - Video Decode: Hardware accelerated
   - Video Encode: Hardware accelerated
   - VPx Video Decode: Hardware accelerated
   - WebGL: Hardware accelerated

Driver Bug Workarounds

   - disable_framebuffer_cmaa
   - disable_multimonitor_multisampling
   - get_frag_data_info_bug
   - needs_offscreen_buffer_workaround
   - pack_parameters_workaround_with_pack_buffer
   - regenerate_struct_names
   - scalarize_vec_and_mat_constructor_args
   - set_zero_level_before_generating_mipmap
   - unfold_short_circuit_as_ternary_operation
   - unpack_alignment_workaround_with_unpack_buffer
   - unpack_overlapping_rows_separately_unpack_buffer
   - use_intermediary_for_copy_texture_image
   - use_shadowed_tex_level_params

Problems Detected

   - Some GPUs on Mac can perform poorly with GPU rasterization. Disable
   all known NVidia GPUs other than the Geforce 6xx and 7xx series, which have
   been tested.: 613272 < http://crbug.com/613272 >, 614468
   < http://crbug.com/614468 >
   *Disabled Features: gpu_rasterization*
   - Work around a bug in offscreen buffers on NVIDIA GPUs on Macs: 89557
   < http://crbug.com/89557 >
   *Applied Workarounds: needs_offscreen_buffer_workaround*
   - Multisampling is buggy on OSX when multiple monitors are connected:
   237931 < http://crbug.com/237931 >
   *Applied Workarounds: disable_multimonitor_multisampling*
   - Unfold short circuit on Mac OS X: 307751 < http://crbug.com/307751 >
   *Applied Workarounds: unfold_short_circuit_as_ternary_operation*
   - Always rewrite vec/mat constructors to be consistent: 398694
   < http://crbug.com/398694 >
   *Applied Workarounds: scalarize_vec_and_mat_constructor_args*
   - Mac drivers handle struct scopes incorrectly: 403957
   < http://crbug.com/403957 >
   *Applied Workarounds: regenerate_struct_names*
   - glGenerateMipmap fails if the zero texture level is not set on some
   Mac drivers: 560499 < http://crbug.com/560499 >
   *Applied Workarounds: set_zero_level_before_generating_mipmap*
   - Pack parameters work incorrectly with pack buffer bound: 563714
   < http://crbug.com/563714 >
   *Applied Workarounds: pack_parameters_workaround_with_pack_buffer*
   - Alignment works incorrectly with unpack buffer bound: 563714
   < http://crbug.com/563714 >
   *Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer*
   - copyTexImage2D fails when reading from IOSurface on multiple GPU types.
   : 581777 < http://crbug.com/581777 >
   *Applied Workarounds: use_intermediary_for_copy_texture_image*
   - Unpacking overlapping rows from unpack buffers is unstable on NVIDIA
   GL driver: 596774 < http://crbug.com/596774 >
   *Applied Workarounds: unpack_overlapping_rows_separately_unpack_buffer*
   - Mac Drivers store texture level parameters on int16_t that overflow:
   610153 < http://crbug.com/610153 >
   *Applied Workarounds: use_shadowed_tex_level_params*
   - Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
   < http://crbug.com/535198 >
   *Applied Workarounds: disable_framebuffer_cmaa*
   - glGetFragData{Location|Index} works incorrectly on Max: 638340
   <http://crbug.com/638340>
   *Applied Workarounds: get_frag_data_info_bug*
   - Raster is using a single thread.
   *Disabled Features: multiple_raster_threads*

Version Information
Data exported 12/13/2016, 10:05:03 AM
Chrome version Chrome/55.0.2883.87
Operating system Mac OS X 10.11.6
Software rendering list version 11.17
Driver bug list version 9.15
ANGLE commit id 4d208abb1926
2D graphics backend Skia/55 d1740f81c843c65acd58d1b571ce94b90fee99d0
Command Line Args Chrome.app/Contents/MacOS/Google Chrome
--flag-switches-begin --flag-switches-end
Driver Information
Initialization time 112
In-process GPU false
Sandboxed true
GPU0 VENDOR = 0x10de, DEVICE= 0x0407 *ACTIVE*
Optimus false
AMD switchable false
Driver vendor
Driver version 10.0.51 310.90.10.05b12
Driver date
Pixel shader version 3.30
Vertex shader version 3.30
Max. MSAA samples 8
Machine model name MacBookPro
Machine model version 4.1
GL_VENDOR NVIDIA Corporation
GL_RENDERER NVIDIA GeForce 8600M GT OpenGL Engine
GL_VERSION 3.3 NVIDIA-10.0.51 310.90.10.05b12
GL_EXTENSIONS GL_ARB_blend_func_extended GL_ARB_ES2_compatibility
GL_ARB_explicit_attrib_location GL_ARB_instanced_arrays
GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sampler_objects
GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding
GL_ARB_shading_language_include GL_ARB_texture_rgb10_a2ui
GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query
GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label
GL_EXT_debug_marker GL_EXT_depth_bounds_test
GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc
GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp
GL_EXT_texture_sRGB_decode GL_APPLE_client_storage
GL_APPLE_container_object_shareable GL_APPLE_flush_render
GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes
GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Disabled Extensions
Window system binding vendor
Window system binding version
Window system binding extensions
Direct rendering Yes
Reset notification strategy 0x0000
GPU process crash count 0
Compositor Information
Tile Update Mode Zero-copy
Partial Raster Enabled
GpuMemoryBuffers Status
ATC Software only
ATCIA Software only
DXT1 Software only
DXT5 Software only
ETC1 Software only
R_8 GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
RG_88 Software only
BGR_565 Software only
RGBA_4444 Software only
RGBX_8888 Software only
RGBA_8888 GPU_READ, SCANOUT
BGRX_8888 GPU_READ, SCANOUT
BGRA_8888 GPU_READ, SCANOUT, GPU_READ_CPU_READ_WRITE,
GPU_READ_CPU_READ_WRITE_PERSISTENT
YVU_420 Software only
YUV_420_BIPLANAR GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
UYVY_422 GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
Log Messages

   - [22080:1295:1212/173906:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/173913:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 3
   - [22080:1295:1212/173928:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/175439:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/175439:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/175439:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/175442:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 0
   - [22080:1295:1212/175714:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/175940:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 0
   - [22080:1295:1212/180536:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 0
   - [22080:1295:1212/180541:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/180603:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 1
   - [22080:1295:1212/180741:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 0
   - [22080:1295:1212/181317:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 0
   - [22080:1295:1212/181317:ERROR:gpu_video_decode_accelerator.cc(365)] : HW
   video decode not available for profile 0
   - [22080:1295:1213/034119:ERROR:latency_info.cc(159)] :
GpuCommandBufferStub::OnAsyncFlush,
   LatencyInfo vector size 1574 is too big.

GPU team, do you see any red flags here?

Gentle ping, could any one from GPU team address this.

Thanks.!

Friendly reminder, Could any one from GPU team address this.

Thank you!

Gentle ping, could any one from GPU team address this.

Thanks.!

kbr@ - any thoughts?

We really should have added a command line argument which would disable the use of the OpenGL Core Profile on all platforms.

Given this bug,  Issue 676829  and  Issue 676975 , I think the problem is that the OpenGL Core Profile that's being used on these older Macs, version 3.3, doesn't work with Chrome's GPU code. Maybe the driver is buggy, or maybe Chrome's making incorrect assumptions about how that OpenGL version worked.

On these older machines where only OpenGL 3.3 is supported as opposed to 4.1, we should try falling back to the compatibility profile. Is there an easy way to let this user try this with a command line flag so we can know whether it would work?

therealjohnparsons@gmail.com - are you willing and able to launch Chrome from the command line in order to test out a fix?

Submitter: please try quitting Chrome and re-launching it from the Terminal like this:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --use-gl=desktop

Does that work around the problem?

We need to hook up the disable_es3_gl_context workaround so that on macOS, it prevents attempting to use the Core Profile. Then the workarounds that were added in  Issue 676829  need to instead just be switched to use disable_es3_gl_context rather than turning off all GPU features.

Mo, could you please take this while I'm OOO next week? Thanks.

Note: came from submitter's reply on:
https://bugs.chromium.org/p/chromium/issues/detail?id=676829#c11

Hi, I can test this with the command line in a couple days. In order to continue working I had to uninstall Chrome 55, then re-install 54 and disable updates in which case everything works great again. I also fiddled with many combinations of flags prior to removing 55. I need to create a separate issue BTW that Chrome 55 takes 6-8 times as long to load and run Google Maps as previous Chrome versions and most transitions - even just entering a location - were so slow and broken (unresponsive to keystrokes and mouse clicks) the product is unusable. Latest updates of Safari and Firefox still run GMaps screaming fast so this GPU support issue impacts usability of Google properties if older Macs are of interest to your product team.

If there is a method to have two different builds of Chrome installed side by side point me to it and I may give the command line version a try sooner.

Folks, I'm seeing something that looks suspiciously similar.  Maybe this will help.

For some Clank UI work in WAT, we're using Javascript to modify button opacity (very simple stuff).  I have a listener registered on a div to modify opacity on mouseenter and leave.  Within the past day or two, this broke, and now opacity changes see the div's image suddenly offsetting itself.  I rolled back the HTML/CSS/JS by weeks, but the break remains, making it feel like something on the rendering side broke (or an older break has been exposed).

I'm in the process of stripping the code down to basics, to make this easy to reproduce, and to make sure it's not a mistake on our end.

I reduced my repro to a single html file with inline styling and script.
- I serve the file on my workstation, and use port-forwarding to let my Pixel load the page.
- I'm running a ToT Chromium for Android debug build as of January 24 (
commit 3d4141d40471d274b0b66d2e938821137bcc0f9c).

Our page has some interesting device-width properties.  Removing these hides (or fixes) the problem.  Maybe this is why reproducing the issue has been difficult.

See attached file.

Deleted: test.html 1.7 KB

test.html 1.7 KB View Download

A little video of what I see is here:
https://goo.gl/photos/hzomK4BqAHB7s1gd8

therealjohnparsons@, if we find this is a separate issue (or not an issue at all), apologies...

Ages ago I used to write video drivers. Having done no review whatsoever of the code involved with this, from the behavior my WAG is that Chrome dropped support for GPU acceleration for the chipset in my older MacBook Pro (NVIDIA GeForce 8600M GT 512 MB) for at least one case that's important for how modern CSS3 is being rendered. Consequently, it's falling back to some Jurassic era alternative rendering techniques based off pre-GPU approaches and relies upon things like over-the-bus frame buffer rendering methods that simply can't run fast enough for smooth transitions; it may also have some flaws lurking in there now with modern page design and CSS mechanism, which were actually quite common back then when CSS was less evolved and pages were simple; maybe nobody every really tested or complained much about non-GPU accelerated CSS3 rendering because on the Mac it was always accelerated. So the result without it, or some newer code that is just being exposed, is that non-accelerated transitions revert to barely more than the first frame and the last frame and black buffer - or partial buffer - contents in between, depending upon the size of the dirty rectangles it's allocated memory for. Along the way, there are some artifacts or old bug(s) that never mattered because it had always been accelerated. Just a guess, but these sorts of issues used to be more common and this looks just like one of those cases. It probably boils down to how much the project team cares about testing on older GPUs like this MacBook Pro. But since things like my site and GMaps render fast and perfectly in "everything but Chrome 55" (i.e Chrome 54 on older Macs, and latest competing browsers on Win/Mac/Nexus) it seems a shame to let the rendering slip.

I bisect shows that our issue must be something else, introduced with a roll of third_party/skia.  Apologies for the distraction.  crbug/684829 has been filed.

Specifically, it behaves like some non-accelerated routine calculates at runtime how many frames/updates it can afford to render within an allotted duration, and sometimes it's just the first and last frame (my case when the window is sized over a certain dimension); other times (cjgrant's Clank) it's miscalculating and stops drawing before even the last frame is correctly rendered.

So, I stand corrected on the second case. But it was nice to learn about the existence of Clank :)

Taking this from Mo.

I just tested this in Version 62.0.3202.62 (Official Build) (64-bit). I now have v54 and v62 installed side by side.  The issue has been resolved - transitions and blurring performance has returned to the pre-v55 rate; Chrome again matches the performance of Safari and Firefox on the test page. Zooming in Google maps has improved but is still not near the pre-v55 buttery smoothness but it's a big improvemen. As the original submitter, I'd give a thumbs up to closing this issue.

Thanks for the feedback. Then we won't disable core profile on this hardware.