New issue
Advanced search Search tips

Issue 718630 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

mouse cursor is blinking while hovering on links, when caret is blinking; only with Mesa & Compositing being Hardware Accelerated

Reported by xftroxgpx@gmail.com, May 4 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3084.0 Safari/537.36

Steps to reproduce the problem:
0. ensure you're running a chromium binary that has Mesa(not Google SwiftShader!) in chrome://gpu  and Compositing must be Hardware Accelerated

1. Open a webpage that has links
example: chrome://gpu/ with the "Problems Detected" section which has links(urls) for the chromium bugs
2. Hover mouse on a link
3. press Ctrl+F to get a keyboard caret blinking (in the search/find field)

What is the expected behavior?
mouse cursor doesn't blink

What went wrong?
mouse cursor blinks once, every time the keyboard caret appears&disappears

Did this work before? N/A 

Chrome version: 60.0.3084.0  Channel: n/a
OS Version: 
Flash Version: 

tested:
mesa 17.0.4
mesa 17.0.5
under DRI3
and DRI2 via: export LIBGL_DRI3_DISABLE=1
With and without this patch for tooltip corruption https://bugs.chromium.org/p/chromium/issues/detail?id=442111#c118

This issue doesn't happen with any of:
1. --use-gl=swiftshader but that's because it does "Compositing: Software only, hardware acceleration unavailable" (for me)
2. --disable-gpu-compositing

Note however that I cannot record the mouse blinking with eg. simplescreenrecorder because it is probably catching it only when it shows, possibly due to vsync.

These chromium binaries [1] won't reproduce this issue because --use-gl=desktop or --use-gl=egl has no effect, they act as if --use-gl=swiftshader
[1] https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F469394%2Fchrome-linux.zip?alt=media

Mouse cursor also blinks* until webpages that are loading in the background are finished. (eg. 'Continue where you left off' is on and you restart browser with many tabs open) But blinks less often when Compositing is Software only.
(*only when hovering on links, of course)
 
gpu.html
58.2 KB View Download
gpu.txt
12.5 KB View Download
xorg.conf.d.tar.xz
3.1 KB Download
Xorg.0.log
109 KB View Download
Another webpage where this can be reproduced (for me) easily is: https://bugs.chromium.org/p/chromium/issues/list

Here's a video where:

1. first half of the video shows that the mouse cursor is blinking when moving the mouse over the links*. The keyboard caret is hidden by keeping selected the text "aa" in the issue search field.
*"links" here meaning that if I were to press LMB it would load a page(the webpage with the chromium issue will load wherever on its horizontal row LMB would happen).

2. second half of the video shows that the mouse cursor is blinking when not moving, while it is left hovering over a link, and the keyboard caret is allowed to exist blinking (the text "aa" is no longer selected, to allow for this). Mouse cursor stops blinking when selecting only one "a" which makes the caret disappear.

issues_mousecursor_blinking_intwoways_MOVI0013.avi.webm
5.3 MB View Download
Now, here's a website where the issue doesn't happen:
https://www.vsynctester.com

Pausing the mouse cursor on the top links of that website, while having caret in Search Box (ctrl+F) will not blink the mouse cursor!(unless there is CPU activity such as disk access and compiling mesa, for example; then it will rarely blink and only when chromium fails to vsync as detected on that very webpage)

However, hovering mouse cursor on the links on the bottom of that webpage, will just make the mouse cursor disappear completely! Sometimes it will blink, but only when vsync-ing fails!(eg. due to spikes in CPU usage)

Including video when no compiling happens in the background: idlecpu_MOVI0014.avi.webm
And video when compiling mesa in the background(which means CPU spikes will cause chromium vsync-ing to fail occasionaly): heavycompiling_MOVI0010.avi.webm
(in next comment)


idlecpu_MOVI0014.avi.webm
5.7 MB View Download
heavycompiling_MOVI0010.avi.webm
9.6 MB View Download
mousecursor_blinking_when_statusbarurl_gets_updated_MOVI0016.avi.webm
1.4 MB View Download
tl;dr: issue still happens without xfwm4 running.

I temporarily removed the window manager (xfwm4, via pkill xfwm4 and made sure it doesn't get autorestarted) and the issue still persists: mouse blinking when hovering on urls.

With latest git xfwm4 though, hovering over links made the mouse cursor disappear completely, and no blinking occurs in tandem with the caret.

Latest xfwm4 commit at the time I tested this was 47cfd5d26ff7f8959bd108c449d3bec1d5d418e3
(but this xfwm4-git has other issues)

omg, I just realized something HUGE:
the mouse cursor blinking(as per OP) does not happen in a clean profile(empty profile dir) regardless of how many times I restart browser, UNTIL I VISIT chrome://gpu ONCE, and then it starts happening after a browser restart.

In other words: issue doesn't happen if I remove the profile dir, then mkdir it, then start chromium, visit any pages, whatever - no mouse blinking. It doesn't matter how many times I restart chromium!
As soon a I visit chrome://gpu once, still no blinking in the current session, but if I restart chromium, from now on the mouse blinking happens and there's no way to make it stop - other than emptying profile dir again.


So, visiting chrome://gpu modifies something in my chromium profile dir (~/.config/chromium) so that next invocations of chromium(eg. restart) will start exhibiting this mouse blinking issue.

tested with:
Chromium	60.0.3091.0 (Developer Build) (64-bit)
Revision	04adc8218cbb4e00dfe6dfa3acd95d07548ed54f-refs/heads/master@{#469835}
OS	Linux
JavaScript	V8 6.0.170
Flash	
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3091.0 Safari/537.36
I can confirm the above still holds true even after removing almost all cmdline args, chrome://gpu now looks like this:

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: Enabled
Native GpuMemoryBuffers: Software only. Hardware acceleration disabled
Rasterization: Software only. Hardware acceleration disabled
Video Decode: Software only, hardware acceleration unavailable
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
adjust_src_dst_region_for_blitframebuffer
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
decode_encode_srgb_for_generatemipmap
disable_framebuffer_cmaa
disable_post_sub_buffers_for_onscreen_surfaces
dont_remove_invariant_for_fragment_input
force_cube_map_positive_x_allocation
force_int_or_srgb_cube_texture_complete
init_texture_max_anisotropy
regenerate_struct_names
remove_invariant_and_centroid_for_essl3
scalarize_vec_and_mat_constructor_args
disable_software_to_accelerated_canvas_upgrade
Problems Detected
Accelerated video decode is unavailable on Linux: 137247
Disabled Features: accelerated_video_decode
Accelerated video encode is unavailable on Linux
Disabled Features: accelerated_video_encode
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Linux AMD drivers incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY: 348237
Applied Workarounds: init_texture_max_anisotropy
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Linux AMD drivers handle struct scopes incorrectly: 403957
Applied Workarounds: regenerate_struct_names
Linux ATI drivers crash on binding incomplete cube map texture to FBO: 518889
Applied Workarounds: force_cube_map_positive_x_allocation
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
Disable partial swaps on Mesa drivers (detected with GL_VERSION): 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Decode and encode before generateMipmap for srgb format textures on os except macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
adjust src/dst region if blitting pixels outside read framebuffer on Linux AMD: 664740
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
AMD drivers in Linux require invariant qualifier to match between vertex and fragment shaders: 659326, 639760
Applied Workarounds: remove_invariant_and_centroid_for_essl3, dont_remove_invariant_for_fragment_input
Mesa driver GL 3.3 requires invariant and centroid to match between shaders: 639760, 641129
Applied Workarounds: remove_invariant_and_centroid_for_essl3
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Decode and Encode before generateMipmap for srgb format textures on Linux AMD: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Software to Accelerated canvas update breaks Linux AMD: 710029
Applied Workarounds: disable_software_to_accelerated_canvas_upgrade
Force integer or srgb cube map texture complete on Linux AMD: 712117
Applied Workarounds: force_int_or_srgb_cube_texture_complete
Accelerated rasterization has been disabled, either via blacklist, about:flags or the command line.
Disabled Features: rasterization
Native GpuMemoryBuffers have been disabled, either via about:flags or command line.
Disabled Features: native_gpu_memory_buffers
Version Information
Data exported	5/6/2017, 3:04:49 PM
Chrome version	Chrome/60.0.3091.0
Operating system	Linux 4.11.0-ga351e9b9fc24
Software rendering list version	13.6
Driver bug list version	10.6
ANGLE commit id	aa7203ef6233
2D graphics backend	Skia/60 7633477b649c36dd2a03c21d799f66193a341182-
Command Line	/usr/lib/chromium/chromium --disk-cache-dir=/tmp/chromiumcache --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	210
In-process GPU	false
Passthrough Command Decoder	false
Supports overlays	false
Sandboxed	false
GPU0	VENDOR = 0x1002, DEVICE= 0x9647
Optimus	false
Optimus	false
AMD switchable	false
Driver vendor	Mesa
Driver version	17.0.5
Driver date	
Pixel shader version	3.30
Vertex shader version	3.30
Max. MSAA samples	8
Machine model name	
Machine model version	
GL_VENDOR	X.Org
GL_RENDERER	Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0)
GL_VERSION	3.3 (Core Profile) Mesa 17.0.5
GL_EXTENSIONS	GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_performance_monitor GL_AMD_pinned_memory GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_AMD_shader_trinary_minmax GL_AMD_vertex_shader_layer GL_AMD_vertex_shader_viewport_index GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_ES2_compatibility GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_base_instance GL_ARB_blend_func_extended GL_ARB_buffer_storage GL_ARB_clear_buffer_object GL_ARB_clear_texture GL_ARB_clip_control GL_ARB_compressed_texture_pixel_storage GL_ARB_conditional_render_inverted GL_ARB_conservative_depth GL_ARB_copy_buffer GL_ARB_copy_image GL_ARB_debug_output GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_derivative_control GL_ARB_direct_state_access GL_ARB_draw_buffers GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_draw_indirect GL_ARB_draw_instanced GL_ARB_explicit_attrib_location GL_ARB_explicit_uniform_location GL_ARB_fragment_coord_conventions GL_ARB_fragment_layer_viewport GL_ARB_fragment_shader GL_ARB_framebuffer_no_attachments GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_get_program_binary GL_ARB_get_texture_sub_image GL_ARB_gpu_shader5 GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_internalformat_query2 GL_ARB_invalidate_subdata GL_ARB_map_buffer_alignment GL_ARB_map_buffer_range GL_ARB_multi_bind GL_ARB_multi_draw_indirect GL_ARB_occlusion_query2 GL_ARB_pipeline_statistics_query GL_ARB_pixel_buffer_object GL_ARB_point_sprite GL_ARB_program_interface_query GL_ARB_provoking_vertex GL_ARB_robustness GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_seamless_cubemap_per_texture GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_objects GL_ARB_shader_precision GL_ARB_shader_stencil_export GL_ARB_shader_subroutine GL_ARB_shader_texture_image_samples GL_ARB_shader_texture_lod GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_stencil_texturing GL_ARB_sync GL_ARB_tessellation_shader GL_ARB_texture_barrier GL_ARB_texture_buffer_object GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_buffer_range GL_ARB_texture_compression_bptc GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map_array GL_ARB_texture_float GL_ARB_texture_gather GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_multisample GL_ARB_texture_non_power_of_two GL_ARB_texture_query_levels GL_ARB_texture_query_lod GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_rgb10_a2ui GL_ARB_texture_stencil8 GL_ARB_texture_storage GL_ARB_texture_storage_multisample GL_ARB_texture_swizzle GL_ARB_texture_view GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_transform_feedback_instanced GL_ARB_uniform_buffer_object GL_ARB_vertex_array_bgra GL_ARB_vertex_array_object GL_ARB_vertex_attrib_binding GL_ARB_vertex_shader GL_ARB_vertex_type_10f_11f_11f_rev GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_ATI_blend_equation_separate GL_ATI_meminfo GL_ATI_texture_float GL_ATI_texture_mirror_once GL_EXT_abgr GL_EXT_blend_equation_separate GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_framebuffer_sRGB GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_polygon_offset_clamp GL_EXT_provoking_vertex GL_EXT_shader_integer_mix GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_texture_shared_exponent GL_EXT_texture_snorm GL_EXT_texture_swizzle GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_IBM_multimode_draw_arrays GL_KHR_context_flush_control GL_KHR_debug GL_MESA_pack_invert GL_MESA_shader_integer_functions GL_MESA_texture_signed_rgba GL_NVX_gpu_memory_info GL_NV_conditional_render GL_NV_depth_clamp GL_NV_packed_depth_stencil GL_NV_texture_barrier GL_NV_vdpau_interop GL_OES_EGL_image GL_S3_s3tc
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Window system binding vendor	SGI
Window system binding version	1.4
Window system binding extensions	GLX_ARB_create_context GLX_ARB_create_context_profile GLX_ARB_create_context_robustness GLX_ARB_fbconfig_float GLX_ARB_framebuffer_sRGB GLX_ARB_multisample GLX_EXT_create_context_es_profile GLX_EXT_create_context_es2_profile GLX_EXT_fbconfig_packed_float GLX_EXT_framebuffer_sRGB GLX_EXT_import_context GLX_EXT_libglvnd GLX_EXT_texture_from_pixmap GLX_EXT_visual_info GLX_EXT_visual_rating GLX_MESA_copy_sub_buffer GLX_OML_swap_method GLX_SGI_make_current_read GLX_SGI_swap_control GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGIX_visual_select_group GLX_INTEL_swap_event
Window manager	Xfwm4
Compositing manager	Yes
Direct rendering	Yes
Reset notification strategy	0x8252
GPU process crash count	0
System visual ID	33
RGBA visual ID	97
Compositor Information
Tile Update Mode	One-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	Software only
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	Software only
BGRX_8888	Software only
BGRA_8888	Software only
RGBA_F16	Software only
YVU_420	Software only
YUV_420_BIPLANAR	Software only
UYVY_422	Software only
Log Messages
[23051:23051:0506/150445.568808:ERROR:sandbox_linux.cc(344)] : InitializeSandbox() called with multiple threads in process gpu-process.
Found the workaround and the reason for Comment 6 happening:

in file "~/.config/chromium/Local State"
if I remove this:
"gl_renderer_string":"Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0)","gl_vendor_string":"X.Org","gl_version_string":"3.3 (Core Profile) Mesa 17.0.5",

then start chromium, there's like no mouse blinking (rarely it blinks but only when background tabs are loading at startup due to "Continue where you left off" setting)

So, as long as that text, those 3 properties are in "Local State" file, then starting chromium will cause the mouse blinking(from OP).

Each per one line:
"gl_renderer_string":"Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0)",
"gl_vendor_string":"X.Org",
"gl_version_string":"3.3 (Core Profile) Mesa 17.0.5",

So, chrome://gpu apparently, is adding those. But why would them existing cause the blinking?
Or is chromium acting like --use-gl=swiftshader if those 3 properties do not exist? Because I know this way there will be no blinking.

I'm including the diff between first run "Local State" and the <after restarting chromium having already visited chrome://gpu> in attachment.

diff.patch
2.2 KB Download
There is a side-effect of not having those 3 key:vals  and that is that some/most tabs now render like an empty white window with a black rectangle at the edge (see screenshot). I'm back to using my normal cmdline options though, but this basically never happens when the 3 key:vals are there and same cmdline options!

This will for sure stop (aka workaround) if I switch to software-only acceleration.
Screenshot_2017-05-06_16-21-45.png
39.3 KB View Download
switching from this tab which works to the non-working tab, doesn't even clear the screen

Screenshot_2017-05-06_16-26-13.png
104 KB View Download
In my main chromium, which has extensions installed, those 3 key:vals get added to 'Local State' for any tab(not just chrome://gpu); tried: gmail inbox, chrome://welcome, google.com

I'm now using this script to get rid of the mouse blinking the next time chromium starts:
srcstatefile="$HOME/.config/chromium/Local State"
tempssf="${srcstatefile}.fixing"
cat "$srcstatefile" | json_reformat|grep -vE '"gl_(renderer|vendor|version)_string"' > "$tempssf"
mv -- "$srcstatefile" "${srcstatefile}.back"
mv -- "$tempssf" "$srcstatefile"
colordiff -up -- <(cat "${srcstatefile}.back"|json_reformat) "$srcstatefile" |less -R

Next, I'll try to figure out which chrome://flags is responsible for the issue in Comment 9 and 10
Well, the issue in Comment 9 and 10 happens without any chrome://flags or cmdline being set, as long as those 3 key:vals are removed from 'Local State' !


/tmp/chromiumcache was removed on startup, just in case.

Here's how chrome://gpu looks in this case.
It doesn't seem to be using SwiftShader like I posited in Comment 8, it's still using Mesa and yet the mouse blinking isn't happening.
gpu.html
55.6 KB View Download
Quick workaround for the issue in Comment 9 and 10 is --disable-gpu-compositing
Consistent way to check for issue from Comment 9 and 10 is:
1. chrome://flags
2. open any drop down list, it will be black
Screenshot_2017-05-06_17-02-36.png
144 KB View Download
args.gn
94.2 KB Download
I wonder if it's possible that some chrome://gpu workarounds do not get applied when those 3 key:vals do not exist in 'Local State'. Currently testing https://bugs.chromium.org/p/chromium/issues/detail?id=339493
Found a more permanent workaround(instead of the bash script) by patching chromium directly to prevent it from adding the 3 key:vals to 'Local State' file, and if they already existed anyway not call the function below. See included patch.

So, here's the thing:
If those 3 key:vals exist in 'Local State' file, when chromium starts up, then this gets run with their values:
content::GpuDataManager::GetInstance()->SetGLStrings(gl_vendor_, gl_renderer_, gl_version_);

If they don't exist, then that doesn't get run!! But chromium does try to write them into 'Local State'

So, something happens after that function gets called:
content::GpuDataManager::GetInstance()->SetGLStrings
that cause the mouse blinking for me(as described in OP)
and when that function doesn't get called, I don't have the blinking issue.

Someone should probably fix/ensure that function gets called (or doesn't at all), even when the 3 key:vals are not in 'Local State' file, if consistency is desired.
I'm thinking this is the reason for Comment 14 (9 & 10) issue happening! As it is for the main OP issue not happening.

localstate_gl_strings_log.patch
1.9 KB Download
That being said, mouse cursor blinking, while it is left hovering on a link, still happens at chromium startup while tabs are loading in the background(assuming current tab is already loaded of course)! Stops blinking when they are done. 'Continue where you left off' setting is on.
Oh there are many important things under that function call that I think should not be missed the first time(empty profile dir ~/.config/chromium/) that chromium starts up.

content::GpuDataManager::GetInstance()->SetGLStrings() calls into
content/browser/gpu/gpu_data_manager_impl_private.cc 's function:

void GpuDataManagerImplPrivate::SetGLStrings(const std::string& gl_vendor,
                                             const std::string& gl_renderer,
                                             const std::string& gl_version)

which does these:
...
  gpu_info.gl_vendor = gl_vendor;
  gpu_info.gl_renderer = gl_renderer;
  gpu_info.gl_version = gl_version;

  gpu::IdentifyActiveGPU(&gpu_info);
  gpu::CollectDriverInfoGL(&gpu_info);

  UpdateGpuInfo(gpu_info);
  UpdateGpuSwitchingManager(gpu_info);
  UpdatePreliminaryBlacklistedFeatures();
}

So, since all this doesn't run for me, I don't experience the mouse cursor blinking but I do experience the Comment 14 issue.
Maybe I should look more into it... but I'm not a programmer so don't expect much.

Comment 20 by ajha@chromium.org, May 10 2017

Components: Internals>GPU
Labels: Needs-Triage-M60
I sort of gave up on this and am just using --disable-gpu
(I'm accepting the lack of vsync, which --disable-gpu-compositing would've given me anyway while trying to avoid the issue in comment 14)

:)

Comment 22 by enne@chromium.org, May 12 2017

Owner: zmo@chromium.org
Status: Assigned (was: Unconfirmed)
zmo, can you take a look at this?

(Thanks for this amazing investigation!!)

Comment 23 by zmo@chromium.org, May 12 2017

Status: WontFix (was: Assigned)
These three local strings prevent Chrome from applying blacklist entry #5, which is disabling GPU acceleration on AMD GPUs.  We decided to allow users to play with AMD GPUs on newer Mesa drivers, and these three local strings are telling Chrome the driver version.

When you remove these strings, it's almost the same as passing in --disable-gpu.  So --disable-gpu is the right solution for you.

I am not sure what further I can do.  Of course we can blacklist AMD gpus totally, regardless of driver versions.  That will gain us some very upset users, shouting that GPU acceleration has been working for them from the beginning of the universe ...
Thanks for taking a look, zmo.
To summarize, these are the issues found so far in this thread:
-------
Issue 1. When chromium is started for the first time (aka the profile dir is empty eg. pass --user-data-dir=/tmp/$RANDOM , and thus 'Local State' file doesn't exist and thus the 3 strings do not exist in 'Local State' file) then chromium acts differently* than any subsequent times it is started(aka when 'Local State' file exists and the 3 strings are present inside it - which chromium automatically adds when it's started)

*By 'differently' I mean see  Issue 2 .

The 3 strings are:
"gl_renderer_string":"Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0)",
"gl_vendor_string":"X.Org",
"gl_version_string":"3.3 (Core Profile) Mesa 17.0.5",
-------
 Issue 2 . When the 3 strings do NOT exist in 'Local State' (aka the first time chromium is started when 'Local State' file doesn't exist at all because the profile dir is empty/non-existent) then the following two things happen differently than when those 3 string DO EXIST in 'Local State'(aka any subsequent time chromium is started):

2a. Comment 14 issue does happen. (a workaround for this to not happen is passing: --disable-gpu-compositing )

2b. Comment 0(aka OP) mouse blinking issue does NOT happen.
(so removing the 3 strings is a workaround for this issue)
(also a workaround for this issue is passing: --disable-gpu-compositing )

-------
 Issue 3 . Mouse blinking when pausing on links happens(between 1 and 4 blinks) while tabs(like 16 of them) are loading in the background, until they're done loading. (eg. have 'Continnue where you left off' enabled in Settings, then open 20 tabs, exit chromium and start chromium). This happens when I pass --disable-gpu (or --disable-gpu-compositing which is really the specific one making the difference here). If I do not pass --disable-gpu-compositing then there seems to be hundreds of blinks while the tabs are loading in the background, when the 3 strings exist in 'Local State'; if they don't exist, then we're back to 1-4 blinks, just as if I passed --disable-gpu-compositing.

-------
I have found blacklist entry #5 in gpu/config/software_rendering_list.json

{                                                                           
      "id": 5,
      "description": "ATI/AMD cards with older drivers in Linux are crash-prone",
      "cr_bugs": [71381, 76428, 73910, 101225, 136240, 357314],
      "os": {
        "type": "linux"
      },
      "vendor_id": "0x1002",
      "exceptions": [
        {
          "driver_vendor": ".*AMD.*",
          "driver_version": {
            "op": ">=",
            "style": "lexical",
            "value": "8.98"
          }
        },
        {
          "driver_vendor": "Mesa",
          "driver_version": {
            "op": ">=",
            "value": "10.0.4"
          }
        },
        {
          "driver_vendor": ".*ANGLE.*"
        }
      ],
      "features": [
        "all"
      ]
    },

I can see this entry in chrome://gpu ONLY when I run chromium with --disable-gpu
I cannot see this entry any other time, whether I remove or keep the 3 strings, whether I pass --disable-gpu-compositing or not. Therefore if this is happening behind the scenes, then chrome://gpu is not reporting it. Besides, this blacklist entry #5 doesn't directly use any of the 3 strings like "id": 68, "description": "Disable partial swaps on linux drivers"  does (Comment 16).
---------

What I do believe is happening is that some blacklist entry(I don't know which!) does not get applied when I see the above 2a issue.
Perhaps the same is true for 2b, or chromium thinks there's no gpu because it doesn't see the 3 strings in 'Local State' file on startup, however chrome://gpu reports it does have hardware acceleration, so it must be the variant with the blacklist entry not being applied because it doesn't see the 3 strings. But it's definitely NOT blacklist entry #5, that's for sure. I thought it was the comment 16 blacklist entry because it was actually using one of the strings 'gl_renderer', but from my tests it wasn't (of course, I could've tested it wrongly believing I was correctly testing it).

Either way, I see some inconsistencies in chromium's behaviour.

Given all this, I believe Comment 23 is incorrect.

I will try to figure out how to print a list of blacklist entries that are applied, maybe this way I can figure out which ones don't get applied when the 3 strings do not exist. I tried to do this before but not-a-programmer:)

I forgot to mention, there is no chrome://gpu difference(s) between when the 3 strings exist and not exist in 'Local State'(, other than the obvious irrelevant ones:

-Data exported	5/13/2017, 6:29:21 AM
+Data exported	5/13/2017, 6:29:50 AM
-Initialization time	337
+Initialization time	277
-[15994:15994:0513/062921.512548:ERROR:sandbox_linux.cc(344)] : InitializeSandbox() called with multiple threads in process gpu-process.
+[16784:16784:0513/062949.088027:ERROR:sandbox_linux.cc(344)] : InitializeSandbox() called with multiple threads in process gpu-process.
)

So, I'm assuming that if there's a blacklist entry not being applied, then chrome://gpu is unable to report it. OR simply this is not a blacklist entry thing, something else must be (not) happening. See my previous comment.
Here we go:
(the following diff is included in attachment also)

fd/63 is when 3 strings exist in 'Local State' file
fd/62 is when they do not

--- /dev/fd/63	2017-05-13 09:45:52.124248305 +0200
+++ /dev/fd/62	2017-05-13 09:45:52.123248318 +0200
@@ -5,8 +5,6 @@ LIBGL_DRI3_DISABLE=1
 test -n 1 -a 01 -eq 1
 extra+=("--disable-gpu-compositing")
 chromium --ssl-version-min=tls1 --disk-cache-dir=/tmp/chromiumcache --disable-sync-preferences --disable-plugins --cipher-suite-blacklist=0x0001,0x0002,0x0004,0x0005,0x0017,0x0018,0xc002,0xc007,0xc00c,0xc011,0xc016,0xff80,0xff81,0xff82,0xff83 '' --disable-gpu-compositing
-!! yes calling content::GpuDataManager::GetInstance()->SetGLStrings(X.Org, Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0), 3.3 (Core Profile) Mesa 17.0.5'
-
 !!! in GpuDataManagerImplPrivate::InitializeImpl
 
 !!! in GpuDataManagerImplPrivate::UpdateGpuInfo, current gpu_info_ vendor= renderer= version= Incoming gpu_info vendor= renderer= version= .Use swiftshader_=0
@@ -52,6 +50,7 @@ Control list match for rule #213 in gpu_
 Control list match for rule #214 in gpu_driver_bug_list.
 Control list match for rule #222 in gpu_driver_bug_list.
 Control list match for rule #223 in gpu_driver_bug_list.
+InitializeSandbox() called with multiple threads in process gpu-process.
 !!! in GpuDataManagerImplPrivate::UpdateGpuInfo, current gpu_info_ vendor= renderer= version= Incoming gpu_info vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 .Use swiftshader_=0
 
 Control list match for rule #48 in gpu_blacklist.
@@ -72,27 +71,12 @@ Control list match for rule #206 in gpu_
 Control list match for rule #210 in gpu_driver_bug_list.
 Control list match for rule #222 in gpu_driver_bug_list.
 Control list match for rule #223 in gpu_driver_bug_list.
-InitializeSandbox() called with multiple threads in process gpu-process.
-!!! in GpuDataManagerImplPrivate::UpdateGpuInfo, current gpu_info_ vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 Incoming gpu_info vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 .Use swiftshader_=0
+!! yes set 'Local State' gl_vendor to new value of 'X.Org' Old was=''
+
+!! yes set 'Local State' gl_renderer to new value of 'Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0)' Old was=''
+
+!! yes set 'Local State' gl_version to new value of '3.3 (Core Profile) Mesa 17.0.5' Old was=''
 
-Control list match for rule #48 in gpu_blacklist.
-Control list match for rule #138 in gpu_blacklist.
-Control list match for rule #54 in gpu_driver_bug_list.
-Control list match for rule #55 in gpu_driver_bug_list.
-Control list match for rule #64 in gpu_driver_bug_list.
-Control list match for rule #88 in gpu_driver_bug_list.
-Control list match for rule #90 in gpu_driver_bug_list.
-Control list match for rule #128 in gpu_driver_bug_list.
-Control list match for rule #172 in gpu_driver_bug_list.
-Control list match for rule #190 in gpu_driver_bug_list.
-Control list match for rule #192 in gpu_driver_bug_list.
-Control list match for rule #199 in gpu_driver_bug_list.
-Control list match for rule #201 in gpu_driver_bug_list.
-Control list match for rule #203 in gpu_driver_bug_list.
-Control list match for rule #206 in gpu_driver_bug_list.
-Control list match for rule #210 in gpu_driver_bug_list.
-Control list match for rule #222 in gpu_driver_bug_list.
-Control list match for rule #223 in gpu_driver_bug_list.
 !!! in GpuDataManagerImplPrivate::UpdateGpuInfo, current gpu_info_ vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 Incoming gpu_info vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 .Use swiftshader_=0
 
 Control list match for rule #48 in gpu_blacklist.
@@ -114,7 +98,7 @@ Control list match for rule #210 in gpu_
 Control list match for rule #222 in gpu_driver_bug_list.
 Control list match for rule #223 in gpu_driver_bug_list.
 
-real	0m13.575s
-user	0m7.489s
-sys	0m2.112s
+real	0m16.149s
+user	0m7.477s
+sys	0m2.049s
 set +x

the.diff
4.2 KB Download
let me put the raw files(2 sets of examples)

with3strings.log
13.7 KB View Download
without3strings.log
11.4 KB View Download
with3strings_2.log
13.5 KB View Download
withOUT3strings_4.log
11.2 KB View Download
Here's another, done the other way around: when the 3 strings were already removed aka first time chromium gets started ever(/dev/fd/63), and then allowed to exist(existing) (/dev/fd/62) aka any subsequent time chromium gets started.

Diff(attached the2.diff):
colordiff -up <(cat /tmp/3stringremoved_3.log|cut -d' ' -f2-) <(cat /tmp/3strings_existing_1.log|cut -d' ' -f2-)|less

--- /dev/fd/63	2017-05-13 10:19:20.820995567 +0200
+++ /dev/fd/62	2017-05-13 10:19:20.820995567 +0200
@@ -5,6 +5,8 @@ LIBGL_DRI3_DISABLE=1
 test -n 1 -a 01 -eq 1
 extra+=("--disable-gpu-compositing")
 chromium --ssl-version-min=tls1 --disk-cache-dir=/tmp/chromiumcache --disable-sync-preferences --disable-plugins --cipher-suite-blacklist=0x0001,0x0002,0x0004,0x0005,0x0017,0x0018,0xc002,0xc007,0xc00c,0xc011,0xc016,0xff80,0xff81,0xff82,0xff83 '' --disable-gpu-compositing
+!! yes calling content::GpuDataManager::GetInstance()->SetGLStrings(X.Org, Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0), 3.3 (Core Profile) Mesa 17.0.5'
+
 !!! in GpuDataManagerImplPrivate::InitializeImpl
 
 !!! in GpuDataManagerImplPrivate::UpdateGpuInfo, current gpu_info_ vendor= renderer= version= Incoming gpu_info vendor= renderer= version= .Use swiftshader_=0
@@ -50,7 +52,6 @@ Control list match for rule #213 in gpu_
 Control list match for rule #214 in gpu_driver_bug_list.
 Control list match for rule #222 in gpu_driver_bug_list.
 Control list match for rule #223 in gpu_driver_bug_list.
-InitializeSandbox() called with multiple threads in process gpu-process.
 !!! in GpuDataManagerImplPrivate::UpdateGpuInfo, current gpu_info_ vendor= renderer= version= Incoming gpu_info vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 .Use swiftshader_=0
 
 Control list match for rule #48 in gpu_blacklist.
@@ -71,14 +72,29 @@ Control list match for rule #206 in gpu_
 Control list match for rule #210 in gpu_driver_bug_list.
 Control list match for rule #222 in gpu_driver_bug_list.
 Control list match for rule #223 in gpu_driver_bug_list.
-!! yes set 'Local State' gl_vendor to new value of 'X.Org' Old was=''
-
-!! yes set 'Local State' gl_renderer to new value of 'Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0)' Old was=''
-
-!! yes set 'Local State' gl_version to new value of '3.3 (Core Profile) Mesa 17.0.5' Old was=''
+InitializeSandbox() called with multiple threads in process gpu-process.
+!!! in GpuDataManagerImplPrivate::UpdateGpuInfo, current gpu_info_ vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 Incoming gpu_info vendor=X.Org renderer=Gallium 0.4 on AMD SUMO (DRM 2.49.0 / 4.11.0-ga351e9b9fc24, LLVM 4.0.0) version=3.3 (Core Profile) Mesa 17.0.5 .Use swiftshader_=0
 
+Control list match for rule #48 in gpu_blacklist.
+Control list match for rule #138 in gpu_blacklist.
+Control list match for rule #54 in gpu_driver_bug_list.
+Control list match for rule #55 in gpu_driver_bug_list.
+Control list match for rule #64 in gpu_driver_bug_list.
+Control list match for rule #88 in gpu_driver_bug_list.
+Control list match for rule #90 in gpu_driver_bug_list.
+Control list match for rule #128 in gpu_driver_bug_list.
+Control list match for rule #172 in gpu_driver_bug_list.
+Control list match for rule #190 in gpu_driver_bug_list.
+Control list match for rule #192 in gpu_driver_bug_list.
+Control list match for rule #199 in gpu_driver_bug_list.
+Control list match for rule #201 in gpu_driver_bug_list.
+Control list match for rule #203 in gpu_driver_bug_list.
+Control list match for rule #206 in gpu_driver_bug_list.
+Control list match for rule #210 in gpu_driver_bug_list.
+Control list match for rule #222 in gpu_driver_bug_list.
+Control list match for rule #223 in gpu_driver_bug_list.
 
-real	0m17.354s
-user	0m7.573s
-sys	0m1.938s
+real	0m17.581s
+user	0m7.553s
+sys	0m1.884s
 set +x



the2.diff
3.5 KB Download
3stringremoved_1.log
8.9 KB View Download
3stringremoved_2.log
8.9 KB View Download
3stringremoved_3.log
8.9 KB View Download
3strings_existing_1.log
11.2 KB View Download
3strings_existing_2.log
11.2 KB View Download

Comment 30 Deleted

Ok, something autodeleted my Comment 30, right after posting it, which was this:

These patches generate those "!!" strings in the logs

with the patches attached

showgpustuff_log.patch
1.9 KB Download
localstate_gl_strings_justlog.patch
1.9 KB Download
So given Comment 26, looks like I'm going to have to add another issue to the list of discovered one in this thread(see Comment 25 for the other 3):

 Issue 4 . chrome://gpu wrongly reports the list of blacklisted entries while some of them aren't actually blacklisted. Since clearly, Comment 29 shows a bunch of them not being applied the first time chromium is started(emulated situation, but still true). Because there's no difference in chrome://gpu output between first time and second+ times.


I figured out how to dump stacktraces from chromium code:
#include "base/debug/stack_trace.h"
base::debug::StackTrace().Print();   

and with it, the meaning of life, the universe and everything: (concurrent incarnations are a thing therefore => we're in a turn-based game)


$ colordiff -up <(cat /tmp/existent3strings_1.log|cut -d' ' -f3-) <(cat /tmp/NONexisting3strings_5.log|cut -d' ' -f3-)>/tmp/the3.diff

Ok look:)) I don't know why the extra (3rd time) of blacklisting happens only when those 3 strings exist in 'Local State' file, but it clearly makes a difference. And I really doubt the devs decided to not blacklist anything the very first time chromium runs(aka start with: --user-data-dir=/tmp/$RANDOM ), and only start blacklisting on any subsequent runs (existing user data dir and thus 'Local State' file with the 3 strings). So at the very least, that could be fixed so it's consistent.
the3.diff
19.9 KB Download
le.patch
2.5 KB Download
le2.patch
2.0 KB Download
existent3strings_1.log
107 KB View Download
existent3strings_2.log
107 KB View Download
NONexisting3strings_3.log
87.1 KB View Download
NONexisting3strings_4.log
87.1 KB View Download
NONexisting3strings_5.log
87.1 KB View Download
existing3strings_6.log
107 KB View Download
Alright let's see what we have here:

+Control list match for rule #48 in gpu_blacklist.
gpu_blacklist is file gpu/config/software_rendering_list.json
#48 is "Accelerated video decode is unavailable on Linux" accelerated_video_decode

+Control list match for rule #138 in gpu_blacklist.
#138 is "Accelerated video encode is unavailable on Linux" accelerated_video_encode

+Control list match for rule #54 in gpu_driver_bug_list.
gpu_driver_bug_list is file gpu/config/gpu_driver_bug_list.json
#54 is "Clear uniforms before first program use on all platforms" clear_uniforms_before_first_program_use

+Control list match for rule #55 in gpu_driver_bug_list.
#55 is "Mesa drivers in Linux handle varyings without static use incorrectly" count_all_in_varyings_packing

+Control list match for rule #64 in gpu_driver_bug_list.
#64 is "Linux AMD drivers incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY" init_texture_max_anisotropy

+Control list match for rule #88 in gpu_driver_bug_list.
#88 is "Always rewrite vec/mat constructors to be consistent" scalarize_vec_and_mat_constructor_args

+Control list match for rule #90 in gpu_driver_bug_list.
#90 is "Linux AMD drivers handle struct scopes incorrectly" regenerate_struct_names

+Control list match for rule #128 in gpu_driver_bug_list.
#128 is "Linux ATI drivers crash on binding incomplete cube map texture to FBO" force_cube_map_positive_x_allocation

+Control list match for rule #172 in gpu_driver_bug_list.
#172 is "Limited enabling of Chromium GL_INTEL_framebuffer_CMAA" disable_framebuffer_cmaa

+Control list match for rule #190 in gpu_driver_bug_list.
#190 is "Disable partial swaps on Mesa drivers (detected with GL_VERSION)" disable_post_sub_buffers_for_onscreen_surfaces

+Control list match for rule #192 in gpu_driver_bug_list.
#192 is "Decode and encode before generateMipmap for srgb format textures on os except macosx" decode_encode_srgb_for_generatemipmap

+Control list match for rule #199 in gpu_driver_bug_list.
#199 is "adjust src/dst region if blitting pixels outside read framebuffer on Linux AMD" adjust_src_dst_region_for_blitframebuffer

+Control list match for rule #201 in gpu_driver_bug_list.
#201 is "AMD drivers in Linux require invariant qualifier to match between vertex and fragment shaders" dont_remove_invariant_for_fragment_input remove_invariant_and_centroid_for_essl3

+Control list match for rule #203 in gpu_driver_bug_list.
#203 is "Mesa driver GL 3.3 requires invariant and centroid to match between shaders" remove_invariant_and_centroid_for_essl3

+Control list match for rule #206 in gpu_driver_bug_list.
#206 is "Disable KHR_blend_equation_advanced until cc shaders are updated" GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent

+Control list match for rule #210 in gpu_driver_bug_list.
#210 "Decode and Encode before generateMipmap for srgb format textures on Linux AMD" decode_encode_srgb_for_generatemipmap

+Control list match for rule #222 in gpu_driver_bug_list.
#222 "Software to Accelerated canvas update breaks Linux AMD" disable_software_to_accelerated_canvas_upgrade

+Control list match for rule #223 in gpu_driver_bug_list.
#223 is "Force integer or srgb cube map texture complete on Linux AMD" force_int_or_srgb_cube_texture_complete
 

Ok, so one(or more?) of these is bad for my OP issue(aka is causing the mouse blinking) and another(or more than one?) is good for avoiding Comment 14 issue. I must find which... next.

Finally, found it it's #190:
  "id": 190,                                                                
      "description": "Disable partial swaps on Mesa drivers (detected with GL_VERSION)",
      "cr_bugs": [339493],
      "os": {
        "type": "linux"
      },
      "gl_type": "gl",
      "gl_version_string": ".*Mesa.*",
      "features": [
        "disable_post_sub_buffers_for_onscreen_surfaces"
      ]
    },


So when this is not applied, then the OP issue is gone, and Comment 14 issue doesn't happen either.

There is however still a bit more blinking happening but only when background tabs are loading and stops when they're done. About 5 times more than normal(so like 20 blinks instead of 4). I may have to find another blacklist entry to remove if I want to decrease these too.

le_no190.patch
905 bytes Download
To reproduce the other mouse blinking issue:

1. hover mouse cursor on a link (such as an issue number link in chrome://gpu)

2. bring up the search dialog (Ctrl+f)
it will blink(19 out of 20 times) when it appears
(It won't blink while the keyboard caret blinks anymore due to the above blacklist entry #190 prevention patch)

3. close search dialog (Esc)
it won't blink here


To workaround it:
two ways:
1. --disable-gpu-compositing
2. clear those 3 strings from 'Local State' file before starting up chromium.
now step 2 will only blink 1 out of 15 times


To fix it, I couldn't find a way yet.

I even tried to prevent blacklisting all those entries that <the missing of the 3 strings> is preventing. But there must be more stuff that that is doing besides that, which is causing this blinking to be less than it is when the 3 strings exist.

Maybe if chrome://gpu would be accurate it would be easier.

Giving up for now...
Cheers.
in
void GpuDataManagerImplPrivate::SetGLStrings(const std::string& gl_vendor,
if I comment out the line
gpu::CollectDriverInfoGL(&gpu_info);
then I can get the same behaviour that chromium has the first time it is started which is the same as passing --user-data-dir=/tmp/$RANDOM and which bypasses applying some blacklist entries(where #5 is not in) but does apply the initial one which doesn't have any effect(where #5 is in).
CollectDriverInfoGL is still called but only after applying the blacklist entries(with #5 in them), which makes me think this is why they don't have any effect. Although some entries are reapplied again afterwards, twice. (#5 is not in these ones) see: chainofevents_with_that_patch.txt
+base::debug::StackTrace::StackTrace()
+gpu::CollectDriverInfoGL()
+gpu::CollectGraphicsInfoGL()
+gpu::CollectContextGraphicsInfo()
+gpu::GpuInit::InitializeAndStartSandbox()
+content::GpuMain()
+content::ContentMainRunnerImpl::Run()
+service_manager::Main()
+content::ContentMain()
+ChromeMain
+__libc_start_main
+_start

In other words, I should stop posting here :)) and focus on something else, like   not bugs...

If I use --disable-gpu-early-init and 'Continue where you left off' setting with chrome://gpu tab last open, I can see an early version of chrome://gpu (with #5 in it) long enough to copy/paste it and then the normal version(without #5) replaces it.

Cheers my friends!
Bye
justlikenothavingthe3strings.patch
822 bytes Download
show_CollectDriverInfoGL_calls.patch
719 bytes Download
early_chrome_gpu.txt
8.7 KB View Download
late_normal_chrome_gpu.txt
13.2 KB View Download
chainofevents_with_that_patch.txt
137 KB View Download
Just want to make an unrelated note here, that I'm deleting my gmail/google account (due to James Damore firing), so, sorry if I don't receive any notifications on any issues that I've reported and therefore won't be able to reply to them.

I figure I can write this here on this issue because it has only 1 star(mine) and likely nobody will notice/be bothered, but those who wonder "where is xftroxgpx?" of why isn't he answering? or why is he ignoring ... well, they can hopefully stumble upon this and not wonder any longer: it's because I've voluntarily deleted my gmail :D

Cheers and best of luck all!

Sign in to add a comment