I'm having the same problem on a retina mac pro. Have to use firefox to watch hulu or youtube in full screen.

Scott, are you the right person for this?  I'm not sure what version of flash is affected.

I'm around the corner in mtv-2000 if you guys want to see it in my laptop.

I'm also seeing this on M26. It drives me crazy. I finally disabled Pepper flash and the problem went away.

To help the developers fix this problem, you might attach a zip file containing the contents of your chrome://gpu and a recording of the choppy playback made with chrome://tracing . 

Advice on tracing:
http://www.chromium.org/developers/how-tos/trace-event-profiling-tool

I posted the results of my problems with 26.0.1395.1 Canary over on Issue 140637.

I noticed that this seemed to only be an issue when the GPU was being switched. using  gfxCardStatus to force either integrated or discrete before starting then video and putting it into fullscreen yielded no lag. Setting it to dynamic switching causes the discrete GPU to be activated as the video is put into fullscreen, and the video then lags.

It does indeed seem to be related to dynamic switching. On Chrome 24 flash PPAPI is always using the integrated video card even on full screen. If I force it to use the discrete video card instead then the same symptoms manifest in chrome 24.

On chrome 25+ I get the same behavior as #8 so it does seem to be related to the dynamic video card switched at least on MBP Retina's.

Still having issues here---

- Chrome version: 25.0.1364.68 beta
- Operating system: OSX 10.8.2
- Video card driver and version # NVIDIA GeForce GT 650M Driver v8.6.22
- ALL full-screen streaming videos.  Safari video is smooth.

- ABOUT:GPU results:

Graphics Feature Status
Canvas: Hardware accelerated
Compositing: Hardware accelerated
3D CSS: Hardware accelerated
CSS Animation: Accelerated
WebGL: Hardware accelerated
WebGL multisampling: Unavailable. Hardware acceleration unavailable
Flash 3D: Hardware accelerated
Flash Stage3D: Hardware accelerated
Texture Sharing: Hardware accelerated
Video Decode: Software only, hardware acceleration unavailable
Video: Hardware accelerated
Panel Fitting: Unavailable. Hardware acceleration disabled.
Force Compositing Mode: Unavailable. Hardware acceleration disabled.
GPU Switching: Automatic switching
Problems Detected
Accelerated video decode is unavailable on Mac and Linux.: 137247, 133828
Enable panel fitting capability on ChromeOS only on IVB and SNB Graphics Controllers.
Multisampling is buggy on Mac with NVIDIA gpu.: 137303
Panel fitting is unavailable, either disabled at the command line or not supported by the current system.
Force compositing mode is off, either disabled at the command line or not supported by the current system.
Version Information
Data exported	2/12/2013 6:52:41 PM
Chrome version	25.0.1364.68 (Official Build 180609) beta
Operating system	Mac OS X 10.8.2
Software rendering list version	4.11
ANGLE revision	1562
2D graphics backend	Skia
Driver Information
Initialization time	5
Sandboxed	false
GPU0	VENDOR = 0x10de, DEVICE= 0x0fd5
GPU1	VENDOR = 0x8086, DEVICE= 0x0166
Optimus	true
AMD switchable	false
Driver vendor	
Driver version	8.6.22
Driver date	
Pixel shader version	1.20
Vertex shader version	1.20
Machine model	MacBookPro 10.1
GL version	2.1
GL_VENDOR	Intel Inc.
GL_RENDERER	Intel HD Graphics 4000 OpenGL Engine
GL_VERSION	2.1 APPLE-8.6.22
GL_EXTENSIONS	GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_separate_stencil GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

I had to do a search for "Chrome Flash Performance Problems" because since a Chrome and a Flash update a few days ago, all audio/video has been sluggish and/or breaking up and interrupted. It will occur when you typing, moving the mouse around rapidly, and its worst with FaceBook window is open and you scrolling around there. A subscriber to Pandora, the music is now horribly breaking up.  This all occur with the latest Chrome update and incidentally a Flash update for FireFox all about the same time.

I hope you experts find this problem. The performance issues is unbearable!

Jason, shouldn't this be a stable blocker, or are we comfortable with this?

I can confirm that Flash is not usable on a stock retina MBP.

I don't think we'd hold here, but will take merges.

I suspect this will break fullscreen flash video on at least all MBP retinas. Unfortunately I don't have any older MBP to test but apple has been shipping laptops with dual video cards for a while.

Extremly annoying in as I'm MBP Retina user. Have to switch for Firefox to see full screen videos. 

I disabled the integrated video card in the settings. It fixed the problem at the cost of less battery life.

7 users have reported this issue in 'GoogleFeedback' since 02/24/2012.

Version :  25.0.1364.97

Users have reported that sync between audio & video has lost when videos are played in full screen mode.

Additional Information: 
1. One user says that videos are getting delayed in full-screen mode.
2. One users says that after sometime of play, video freezes. 
3. One user reported that it happens with 15" Retina Display MacBook Pro.
4. Playing in normal mode will resolve the issue.
5. Issue appears only in Mac 10.8 and Mac 10.7 Operating System.

NOTE: We could not reproduce the issue on Chrome (26.0.1410.12) M26 Beta version on Linux.

Sample user reports:
http://goto.google.com/393097958
http://goto.google.com/716939875
http://goto.google.com/656572892
http://goto.google.com/640491701

For more user reports refer the cluster URL:
http://goto.google.com/4390458

YouTube video plays good in fullscreen mode in current stable 25.0.1364.152 on OS X 10.7.5
I'll update the bug after checking on a 10.8 machine

Videos are playing good in fullscreen in 25.0.1364.152 on OS X 10.8.2 as well. Please check in this stable version. Feel free to update the thread.

Chrome updated to Version 25.0.1364.152 automatically for me today.  I'm running on OS X v10.8.2 on a Retina Mac Book Pro.  The out of sync video is not fixed for me.  I did restart Chrome and even went so far as to reboot the computer.

When I click to go to full screen, the screen goes completely white for about a second before the video displays.  The audio plays continuously without break.  In fullscreen, the video lags behind the audio.

The attached file has the GPU info and a tracing done by starting a youtube video, starting tracing, clicking fullscreen on the video, clicking out of fullscreen, and stopping the tracing.

chrome-issue-171911.zip 2.6 MB Download

Same problem still persists here also.

I have the exact same issue! This is bad. I can only watch videos in Chrome when it's windowed... v23 was very slow, v24 was perfect, and now v25 is broken again on MBPr in OS X. :-(

I'm having the exact same issues on my 15" MBP retina running OSX 10.8.2 with Chrome 25.0.1364.152. Runs fine in Safari but extremely jittery/choppy in Chrome (completely unwatchable). Turning off the 'Automatic graphics switching' option in the Energy Saver menu fixes the issue but naturally I hope this isn't a permanent solution as it's currently destroying my battery life.

Another point is that when playing videos fullscreen though Chrome on a monitor (via HDMI at 1080p) the play back is significantly better (watchable) but still noticeably not smooth.

I tried to attach a trace of a youtube video but I would not allow me to submit a comment with it attached.

Anything else I can do to help let me know

Apologies it appears the trace file was to big so here it is compressed.

It's from a Youtube video where is it paused, enters fullscreen (including white screen first), plays, leaves full screen while still playing the video windowed (no issues), then paused.

Trace.zip 1.7 MB Download

I've been having this problem recently too.  Every single youtube video has been play perfectly in windowed mode, but lagging and unwatchable when full screened.

chrome://gpu and chrome://tracing attached.

NPAPI is disabled, only PPAPI is available.

Google Chrome	25.0.1364.152 (Official Build 185281) 
OS	Mac OS X 
WebKit	537.22 (@144108)
JavaScript	V8 3.15.11.16
Flash	11.6.602.171

gputrace.zip 4.0 MB Download

chrome_gpu.html 33.9 KB View Download

Yes, I have the same as reported here. MBP 15" Retina, OSX 10.8.2 with Chrome 25.0.1364.152. Full screen video goes to white screen, then laggy choppy video. This has only started happening fairly recently.

I am around in 1950 if you can't repo it.  Feel free to ping me, I have a live specimen.

Same problem here.

Chrome 25.0.1364.99
MBP retina OS X 10.8.2

This audio sync test on YouTube demonstrates the problem nicely for me (http://www.youtube.com/watch?v=bCPEidaVzQU). It works fine at normal size, but has issues in full-screen. Unchecking the "Automatic graphics switching" box in energy saver system preferences seems to make full-screen better.

A report from Japanese user as well: 

MacBook Pro Retina 15inch
Core i7　2.3GHz | RAM 8GB | OS X　10.8.2
Chrome  25.0.1364.99

Flash plugin        11.6.602.171 /Applications/Google Chrome.app/Contents/Versions/25.0.1364.99/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin 
Flash plugin        11.6.602.171 /Library/Internet Plug-Ins/Flash Player.plugin (not used) 

--- GPU driver, more information --- 
Vendor Id        0x10de 
Device Id        0x0fd5 
Driver vendor         
Driver version        8.6.22 
Driver date         
Pixel shader version        1.20 
Vertex shader version        1.20 
GL version        2.1 
GL_VENDOR        Intel Inc. 
GL_RENDERER        Intel HD Graphics 4000 OpenGL Engine 
GL_VERSION        2.1 APPLE-8.6.22 
GL_EXTENSIONS        GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_separate_stencil GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod 


--------------------------------------------------------------------------------------- 

Graphics Feature Status 
Canvas: Software only. Hardware acceleration disabled. 
Compositing: Hardware accelerated on all pages and threaded 
3D CSS: Hardware accelerated 
CSS Animation: Accelerated and threaded 
WebGL: Hardware accelerated 
WebGL multisampling: Unavailable. Hardware acceleration unavailable 
Flash 3D: Hardware accelerated 
Flash Stage3D: Hardware accelerated 
Texture Sharing: Hardware accelerated 
Video Decode: Software only, hardware acceleration unavailable 
Video: Hardware accelerated 
Panel Fitting: Unavailable. Hardware acceleration disabled. 
Force Compositing Mode: Hardware accelerated 
GPU Switching: Automatic switching 
Problems Detected 
Accelerated video decode is unavailable on Mac and Linux.: 137247, 133828 
Enable panel fitting capability on ChromeOS only on IVB and SNB Graphics Controllers. 
Multisampling is buggy on Mac with NVIDIA gpu.: 137303 
Accelerated 2D canvas is unavailable: either disabled at the command line or not supported by the current system. 
Panel fitting is unavailable, either disabled at the command line or not supported by the current system. 
Version Information 
Data exported        2013/3/1 13:58:01 
Chrome version        25.0.1364.99 (Official Build 183764) 
Operating system        Mac OS X 10.8.2 
Software rendering list version        4.11 
ANGLE revision        1562 
2D graphics backend        Skia 
Driver Information 
Initialization time        6 
Sandboxed        false 
GPU0        VENDOR = 0x10de, DEVICE= 0x0fd5 
GPU1        VENDOR = 0x8086, DEVICE= 0x0166 
Optimus        true 
AMD switchable        false 
Driver vendor         
Driver version        8.6.22 
Driver date         
Pixel shader version        1.20 
Vertex shader version        1.20 
Machine model        MacBookPro 10.1 
GL version        2.1 
GL_VENDOR        Intel Inc. 
GL_RENDERER        Intel HD Graphics 4000 OpenGL Engine 
GL_VERSION        2.1 APPLE-8.6.22 
GL_EXTENSIONS        GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_separate_stencil GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod 


Original forum thread: https://productforums.google.com/forum/#!category-topic/chrome-ja/rXRmcigfq9I

This is reproducible in 27.0.1430.0 Canary on OS X 10.7.5
Audio and video go out of sync when switched to fullscreen mode

same problem, MBP Retina, Version 25.0.1364.152 Chrome, 10.8.2.

White screen when pressing full screen, then extremely choppy playback. what to do?

I am having the same problem. MBP Retina, Chrome Version 25.0.1364.155.

I am experiencing very similar symptoms as described by many above: when I hit full screen the screen goes black or white for a second or two, and then the audio is terribly out of sync, and the video seems slightly choppy (but it is mostly the audio sync that is killer).

I have tried disabling, and even uninstalling what few plugins I had installed. Tried rebooting. Tried a lot of things.

This issue started happening very recently, and they did roughly coincide with installing some OS updates.

I do not have the same issue in Safari.

I am running the latest version of Flash.

OSX 10.8.2, Build 12C3012

Same problem here: flickering, lagging and breaking video/areas of video when entering fullscreen mode.

Details:

15" MacBook Pro Retina:
OS X 10.8.2

Chrome:
Version 25.0.1364.155

Adobe Flash Player (2 files) - Version: 11.6.602.171
Shockwave Flash 11.6 r602
Name:	Shockwave Flash
Description:	Shockwave Flash 11.6 r602
Version:	11.6.602.171
Location:	/Applications/Google Chrome.app/Contents/Versions/25.0.1364.155/Google Chrome Framework.framework/Internet Plug-Ins/PepperFlash/PepperFlashPlayer.plugin
Type:	PPAPI (out-of-process)
 	 Disable
MIME types:	
MIME type	Description	File extensions
application/x-shockwave-flash	Shockwave Flash	
.swf
application/futuresplash	FutureSplash Player	
.spl
Name:	Shockwave Flash
Description:	Shockwave Flash 11.6 r602
Version:	11.6.602.171
Location:	/Library/Internet Plug-Ins/Flash Player.plugin
Type:	NPAPI
 	 Disable
MIME types:	
MIME type	Description	File extensions
application/x-shockwave-flash	Shockwave Flash	
.swf
application/futuresplash	FutureSplash Player	
.spl

Note:
Disabling PepperFlash/PPAPI solves the flickering areas and overall flickering in fullscreen, but then the videos start breaking/lagging.

Having the same issue on the rMBP.

Some of my observations,

When using chrome I am able to watch videos fine as long as not in fullscreen, switching to fullscreen causes my macbook screen to go white for a couple of seconds then starts stuttering. I noticed that when this happens initially it is using integrated graphics and when coming out of fullscreen I see my graphics card coming out of dedicated. You can check this with gfxcardstatus - so i'm assuming when you see that white screen your graphics card switches to dedicated causing a sync issue and begins stuttering.

There's 2 temporary solutions:

1. Get gfxcardstatus and force integrated graphics- meaning that apps won't be able to switch to discrete. Doing this works perfectly no stutter while watching fullscreen.

2. Disable PPAPI and use NPAPI in chrome plugins - the only issue is that controls on youtube look blurry.

Both firefox and safari do not have this issue, and I hope google can fix this.

The issue is not only affecting Full Screen video, we are seeing noticeable differences in frame rate and audio/video sync in our video conferencing application.  We are advising all of our users to disable PepperFlash to work around this issue.  Perhaps Google can work with Adobe engineers to resolve this issue! 

Issue 180131 has been merged into this issue.

I confirm this is happening on Linux also. However it is not always reproducible. Some videos are sluggish.

Chromium	25.0.1364.160 (Developer Build 186726) 
OS	Linux 
WebKit	537.22 (Unknown URL@0)
JavaScript	V8 3.15.11.16
Flash	11.6.r602
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22


Name:	Shockwave Flash
Description:	Shockwave Flash 11.6 r602
Version:	11.6.602.171
Location:	/usr/lib/PepperFlash/libpepflashplayer.so
Type:	PPAPI (out-of-process)
 	 Enable
MIME types:	
MIME type	Description	File extensions
application/x-shockwave-flash	Shockwave Flash	
.swf
application/futuresplash	FutureSplash Player	
.spl

gpu.txt 6.1 KB View Download

Exact same issue on my 2012 15" Macbook Pro Retina.

- Video plays fine (youtube, hulu, netflix, vimeo, whatever)
- Switching to full screen yields a white screen for a half second, then the audio is completely out of sync, by about a second or so, half second maybe.
- This does not occur in Safari. Only Google Chrome.
- It's clearly a gpu issue. 

Either the OS X 10.8.3 update or the MBP retina SMC update v1.1 seems to have fixed this issue for me, or at least greatly reduced it. I'm on a 15" Macbook Pro Retina running Chrome 27.0.1438.7 dev.

Same problem here, after upgrading to Mac OS X 10.8.3 yesterday. Videos play smoothly until I switch to fullscreen mode. I get the white screen for half a second as well.

No issues in Safari, so I have to use a different browser than Chrome to watch videos.

15" MacBook Pro Retina, Chrome 25.0.1364.172

MBP Retina Mac OS X 10.8.3
Chrome Version 25.0.1364.172

Same problem in fullscreen mode. 
Disable GPU switching in the Energy Saver menu in order to solve it TEMPORALY

Someone commented to me offline about this bug earlier today.  I have been aggressively ignoring it, so I didn't realize it was assigned to me.  I don't have time to work on this.  This isn't a value judgement about whether it's a real or important bug: there are literally more things trying to claim my time than I have time to work on them, so something has to give.

Hi, Anthony.

Is there anyone from Adobe that could take a look? Thanks a lot!

It sounds like this may be an issue with GPU-switching on these machines. We have a fix for one problem like that in Canary, so maybe people should try that out to see if it helps.

I just tried the canary:

Google Chrome	27.0.1444.3 (Official Build 188745) canary
OS	Mac OS X 
WebKit	537.35 (@145978)
JavaScript	V8 3.17.12
Flash	11.7.700.141

The problem is still the same and reliably reproducible every time.

On a 13" retina macbook pro (which does not have a second graphics card and therefore doesn't switch) this problem exists as well.  OS X 10.8.3 and Chrome 25.0.1364.172  Problem does not occur in Firefox or Safari.   

same problem here on 10.8.3 on a macbook 13" mid 2010 and with Chrome 25.0.1364.172. In all youtube/vimeo videos but only in full screen mode i see stutters... very annoying....

This is extremely noticeable on Retina MBPs and a significant regression. Can we get an owner?

Same here, stuttering in fullscreen on Mac OS 10.8.3 + Chrome 25.0.1364.172. Does work fine in Firefox / Safari and used to work fine on Chrome as well (until a couple of weeks ago)

Jeff, what should we do here?

I talked to Ilja and I think this maybe a Chrome GPU issue.
People are reporting that this bug happens when switching between the integrated and discreet graphics card.
Pepper Flash on Mac does software video decoding so this is probably not a Flash bug.

+vangelis to comment on c#56

c#50 seems to indicate GPU switching may not be the case, but I don't have a 13" rMBP to test with.

I would agree with c#58. I am running Chrome  25.0.1364.172 on OS X on a 15" retina MBP. I get the same slowdown in fullscreen flash whether I have automatic GPU switching enabled or not.

I got the slowdown also both with "Automatic graphics switching" on and off.

The problem has just been solved by disabling Pepperflash. Even now with Pepperflash back enabled everything seems to be working just fine again.

It seems we have conflicting info about whether this is a Chrome GPU issue or a Flash issue.

I'll wait to hear what Vangelis thinks.

Adobe Flash QA is cc'ed on this bug. Anthony/Jose, any thoughts?

+wiltzius in case this ends up being a Chrome GPU issue

I forgot to add the report from my contractor but his findings support @56 

http://code.google.com/p/chromium/issues/detail?id=171911 where the audio and video go out of sync in full screen when automatic graphic switching is enabled on a Retina display. It works fine with the automatic graphic switching option disabled.

The injection point for this seems to be 170790. The two graphic cards on my machine are a Intel HD Graphics 4000 and a NVIDIA GeForce GT 650M. There was a notable difference with this build and the build preceding it. With the injection build, playing the video in normal mode uses the Intel card and when you switch to full screen, it switches to the Nvidia card. However, with the previous build, it uses the Nvidia card with both normal mode and full screen mode even with the automatic graphic switching on.

I just used a Youtube video to test with. I have also attached my about:GPU.

Fail - Mac 10.8.2 / Chrome 25.0.1348.0 (170790) / Pepper 11.6.602.171 
Pass - Mac 10.8.2 / Chrome 25.0.1348.0 (170742) / Pepper 11.6.602.171

*FYI, for some reason sometimes even the passing builds will sometimes start to have their audio and video start going out of sync. This made finding the injection point very difficult. I found restarting the machine fixes this issue. With the injection build, it will consistently fail even with a computer restart.

Thanks Anthony.

Note: When Adobe says "injection", they mean "regression".

I have the same issue with my 15" Retina MacBook Pro. Stuttery videos and out of sync audio when playing videos in fullscreen mode. Works flawlessly in Safari.

We are seeing the issue in non-Mac, Windows Chrome as well.  This is not Mac GPU specific.  This is a chrome/pepperflash issue.

The symptoms are generic, so let's try to narrow this down to one specific issue. @Adobe QA, can you confirm if the same problem (i.e. a full-screen Flash video performance regression around 170790) exists or not on non-Mac platforms, or 13" Retina Macs (i.e. machines with only integrated GPUs)?

If not, sounds like its the integrated/discrete switching. In that case we can look at if anything's changed w.r.t. the switching policy. We should be using the discrete Nvidia GPU in full-screen Flash on 15" MBPs (we made this change last fall).

Last time I checked, M24 wasn't switching to the discrete CPU and it didn't exhibit the performance issues.

Even with M24, if I forced the switch while chrome was open using other means (ie: opening mplayer), the issues with chrome fullscreen would appear.

I'm currently sitting in MTV-2000. I can show you guys all of these if you want. I'm pretty sure at this point this is caused by switching the graphics card while chrome is running.

@jbauman has been working on fixing gpu switching perfomrance issues.  John, is our latest and greatest currently in Canary? 

@Anthony (Adobe QA), you said in comment #63: "The injection point for this seems to be 170790"

But crrev.com/170790 seems to be a ChromeOS-only change, unless I'm mistaken. Is 170790 really what you meant?

Based on #63 - http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Fbranches%2F1410%2Fsrc&range=170790%3A170742&mode=html

I don't see any change to be suspicious. I'll ping Chrome QA to find out if they can bisect it.

I downgraded to chrome stable so that I could avoid this problem, but today stable upgraded to 26.0.1410.43 and the issue is back.

@Jeff No, my contractor believes the regression range to be 170742 - 170790. We just use the continuous builds for ease. According to his results the Nvidia GPU was always utilized for both FS and windowed, but with switching resulted in worse behavior. 

FWIW none of the rev's jump out at me like 71 mentioned

On canary this happens not to be an issue anymore, because we're not forcing the use of the discrete GPU. However, I can make it still happen by forcing the discrete GPU in gfxCardStatus before starting chrome, so it doesn't seem related directly to Chrome's GPU switching. It looks like it spends a ton of time in CGLFlushDrawable in CompositingIOSurfaceMac::DrawIOSurface, so maybe we're doing something wrong when creating the window that's being drawn to.

Bisected on 15" MBP Retina on OS X 10.8.3

Working build: 25.0.1347.4
Broken build: 25.0.1348.0

Corresponding CL:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=170692:170890&mode=html

There are at least two GPU-related changes here

http://src.chromium.org/viewvc/chrome?view=rev&revision=170700
http://src.chromium.org/viewvc/chrome?view=rev&revision=170776

@James or @David, what do you think?

170776 is about PBOs which I do not think we use on mac today.

170700 is about texture sharing blacklisting which isn't a concept that exists on mac, afaik.

170776 just allows resizing of buffer objects to 0. Only impl-side painting will do that so I'm pretty sure this rev is not related to this bug.

The performance improves if I use the new Lion fullscreen, though that changes the behavior somewhat so I don't know if it's acceptable.

+Mac folks

Personally I think it's fine to change the Pepper Flash fullscreen behavior on Mac (the change is subtle, anyway) in order to significantly improve performance.

Personally, the Lion fullscreen mode drives me absolutely insane. I'd much rather see the root cause be fixed, but at this point I'll take what I can get.

Do we understand why lion fullscreen helps?

It sounds like this was a regression; it should be possible to bisect locally to find the exact revision where things went south.

This has been bisected twice and they show similar range. However, we couldn't able to identify the culprit change. Could one of you look at the range again?

Adobe QA bisected range: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=%2Fbranches%2F1410%2Fsrc&range=170790%3A170742&mode=html

Chrome QA bisected range:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=170692:170890&mode=html

I mean: an engineer can bisect with single revision precision (by building locally, not by running the bisection script).

Could: 
http://src.chromium.org/viewvc/chrome?view=rev&revision=170782

have something to do with it?

I doubt it. Constrained windows are these sheets that come up for http auth, to confirm form submission, print preview, etc. This code isn't used if none of these sheets is visible.

http://src.chromium.org/viewvc/chrome?view=rev&revision=170782 probably doesn't have anything to do with this. I'll try and do a bisect to see what changes could possibly do this.

As for why Lion fullscreen is different from the one we're using, it's hard to know for sure, but I think they're compositing the window differently in the mode we're using, perhaps trying to improve performance by reducing copies. This somehow has a bad interaction with the discrete GPU, but I don't know anything more than that at the moment. I may try playing around with the NSOpenGLPixelFormat it's using to see if we're somehow making it incompatible with full-screen.

It looks like the issue might be caused by http://trac.webkit.org/changeset/136332, though I can't explain why. It seems like the performance issue caused by that change is different from the performance issue we have now. Previously, it seemed that forcing the discrete GPU with gfxCardStatus before starting chrome solved the problem, while with today's Chrome that doesn't seem to help. Also the trace results seem pretty different.

27.0.1438.7 Dev worked fine for fullscreen on the retina, maybe this could be of use to you guys.

I'd like to revert r165513 on M26, as it seems to be causing more harm than good. (I can't revert it on trunk, as all the code has completely changed to make it unnecessary.)

------------------------------------------------------------------------
r191085 | jbauman@chromium.org | 2013-03-28T01:28:05.498311Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1410/src/content/renderer/render_widget_fullscreen_pepper.cc?r1=191085&r2=191084&pathrev=191085

Revert 165513 "Make fullscreen Flash use the discrete GPU"

> Make fullscreen Flash use the discrete GPU
> 
> The integrated GPU on some Macs (particularly Retina MBPs) is a bit underpowered for displaying fullscreen Flash, so switch to the discrete GPU in that case. We may eventually want to find out a better heuristic.
> 
> 
> BUG= 158123 
> 
> 
> Review URL: https://chromiumcodereview.appspot.com/11275106

TBR=jbauman@chromium.org
BUG= 171911 
Review URL: https://codereview.chromium.org/13116025
------------------------------------------------------------------------

So hopefully this will mostly work ok on M26. For M27 and M28 (and M26 in unusual situations), there's still a performance problem when the normal Chrome window is redrawn while there's a fullscreen Flash window. This is now being triggered all the time by r185715 (adding an audio indicator to the tab).

I wonder if there's a clue in there.  I poked around a bit yesterday with Quartz Debug, and Safari's plugin-process window in fullscreen has Alpha 1.00 - Opaque, while our fullscreen window has Alpha 1.00 - Meshed.  When I dug around, I see that we set opacity off for windows in UnderlayOpenGLHostingWindow, and I don't think it's wrong, but I do wonder if the system might not be keying off that setting when making redrawing decisions.  I _think_ that regular Chrome windows will have basically the same settings, but it's entirely possible that there is some additional factor regular Chrome windows are adding which the ppapi fullscreen window isn't doing.

I also notice that on my beefy desktop with non-beefy display (1600x1200), fullscreen drops more frames than non-fullscreen, but not nearly so many as my laptop.  So another thing I wonder about is Trung's point about event starvation.  I don't know if there's a bug about that, but the gist of it is that on Windows, Chrome events (posted tasks, etc) are in the same queue as GUI system events (mouse clicks, etc).  On OSX, our event pump sits in the queue with system events, so multiple system events might be pumped between each Chrome event, and system events can actually starve Chrome events (like animating all the spinners on session restore).  In this scenario, it's not the drawing itself which causes the problem, it's the events which lead to the drawing starving something in Chrome, which would be more pronounced when the load is near the system's capacity.  I think.  Maybe.

Thanks for looking into this, Scott. It does seem that making the window opaque works - https://codereview.chromium.org/13219004/ . 

Hi there,

Adding Hotlist Conops to this thread as an FYI as a few users are reporting this in our Help Forum (see thread below). 

Forum Thread: https://productforums.google.com/forum/#!topic/chrome/sGc0o1zOtqs

Thanks,
Div

------------------------------------------------------------------------
r191271 | jbauman@chromium.org | 2013-03-29T02:28:43.360064Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_view_mac.mm?r1=191271&r2=191270&pathrev=191271

Set pepper flash fullscreen window to opaque.

CGLFlushDrawable was taking a really long time when presenting to a fullscreen pepper flash window when using a discrete GPU while the Chrome window was also being drawn to. Setting the window to opaque seems to fix that, and still works because the GL content is always drawn on top of the Flash window, and not underneath.

BUG= 171911 


Review URL: https://chromiumcodereview.appspot.com/13219004
------------------------------------------------------------------------

Issue 224820 has been merged into this issue.

i assume it's for 191271? let's let it go to canary first.

talked to john, we'll let this bake a bit more.

For any testers working to confirm when this bug is fixed, please make sure you run a simple test case that is I believe is also related to this bug.

1. Open a tab that runs any kind of flash content, whether its a game or video or whatever. Make sure the gfxcard status is still on integrated.
2. With the flash content running, open any program that forces the video card over to discrete, VLC will cause this.
3. Flash content will suddenly stop rendering, you can go backwards and forwards in history and all you'll see is that frozen frame. Audio will continue to work as well as any code running in the flash player.
4. Quit VLC to allow the video card back to integrated and flash rendering will resume.

This bug doesn't occur on Firefox and Safari.

sean.christmann, if that issue is happening when Flash isn't fullscreen, then it's a separate bug and you should file a new bug report for it. I would also recommend trying on Chrome 26 or Canary to see if it's fixed there.

jbauman, i can if needed, I assumed the root bug being discussed here was problems with graphics switching, not fullscreen specifically.

sean.christmann, given the title this bug is specifically about performance. I'd say file a new one :)

Hi, I was on issue 162109 when this was linked, so I just tried Chromium 28.0.1460.0 (191616) in a rMBP 15 using thedailyshow.com and the experience is as follows:
- discrete kicks in as soon as flash starts playing in window (not nice)
- there is perfect flash playback in fullscreen (nice)
- discrete stays engaged after closing window with flash content (not nice, but do dice because I did not wait that long for the helper process to decide that it is a good idea to release the discrete graphics)

More testing available on demand.

jbauman and leviw.

Done! Its actually a good thing because while testing it I found out this isn't just a flash thing, its affecting canvas and html5 video as well when the gpu switches. I submitted it as issue 225526 but now trying to link to it I've noticed its just been deleted, not sure why.

I am having this issue as well. I have confirmed that disabling PepperFlash sort of resolves the issue however with Adobe's discreet version of flash there is another issue where the graphics card on my 15" retina MBP won't switch back to the integrated GPU even after closing the window where flash video was playing (the only way to revert to the integrated GPU is by quitting Chrome completely). This is really annoying as the discrete GPU destroys battery life.

Disabling Pepper Flash is strongly discouraged, as the standalone version of Flash is not sandboxed. jbauman's r191271 should have fixed the performance issue in Canary.

so how is this looking on canary? do we feel strongly we want/need it in m27?

This is working on canary for me.

Watching fullscreen videos in youtube is probably a major use case for Chrome, and should work with or without NPAPI flash.  I think it'd be a good idea to put it in m27.

Yeah, this seems to be working fine in canary, and I think it would be a very good idea to have it in m27.

I can't think of any downside.  If it broke accelerated compositing, I think we'd already know, and I don't think this kind of change is likely to have any stability impact at all.

Since I didn't have M-27 conveniently on my MBP/retina, I tried comparing a fullscreen video between M-26 and M-28.  Tons of dropped frames on M-26.  I kind of think we should consider shipping the change all the way down to stable.

M26's problems should mostly be fixed by r191085, which hasn't been released yet. We may want to backport r191271 back to M26, but it won't matter as much there.

ok let's go ahead for m27. ty.

------------------------------------------------------------------------
r192414 | jbauman@chromium.org | 2013-04-04T23:18:02.767690Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1453/src/content/browser/renderer_host/render_widget_host_view_mac.mm?r1=192414&r2=192413&pathrev=192414

Merge 191271 "Set pepper flash fullscreen window to opaque."

> Set pepper flash fullscreen window to opaque.
> 
> CGLFlushDrawable was taking a really long time when presenting to a fullscreen pepper flash window when using a discrete GPU while the Chrome window was also being drawn to. Setting the window to opaque seems to fix that, and still works because the GL content is always drawn on top of the Flash window, and not underneath.
> 
> BUG= 171911 
> 
> 
> Review URL: https://chromiumcodereview.appspot.com/13219004

TBR=jbauman@chromium.org
Review URL: https://codereview.chromium.org/13529008
------------------------------------------------------------------------

This is fixed for me on 28.0.1464.0 dev

This issue is Pri-1 but has already been moved once, therefore lowering to Pri-2 and moving to next milesone

This Sucks, I always have to switch to safari when video is out of sync

Confirming Chrome 26 consumer does not play full screen on Retina MacBookPro - Vimeo works flawlessly though.

@125 would you mind filing a new bug for your issue? Please include chrome://gpu page in the new bug as well. 

Should this bug be locked? 

This seems to be fixed for me in the latest beta build (27.0.1453.65)