Nightly bad scrolling performance on Windows7 with intel sandy bridge cpu/gpu
Categories
(Core :: Graphics, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox107 | --- | wontfix |
| firefox108 | --- | verified |
| firefox109 | --- | verified |
People
(Reporter: fj2d8jd, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(5 files, 1 obsolete file)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
dmeehan
:
approval-mozilla-release-
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
Steps to reproduce:
starting from this build -> https://archive.mozilla.org/pub/firefox/nightly/2022/09/2022-09-23-21-21-51-mozilla-central/firefox-107.0a1.en-US.win64.installer.exe
video performance got pretty bad on my win7 x64 system powered by an Intel Pentium G850 sandy bridge CPU/GPU, driver version 9.17.10.4229
previous build could do 60fps scrolling just fine -> https://archive.mozilla.org/pub/firefox/nightly/2022/09/2022-09-23-09-30-59-mozilla-central/firefox-107.0a1.en-US.win64.installer.exe
steps to reproduce the issue:
-
an intel sandy bridge system with windows7 x64 is needed along with a fullhd capable screen.
-
install nighty latest "good build" from this link https://archive.mozilla.org/pub/firefox/nightly/2022/09/2022-09-23-09-30-59-mozilla-central/firefox-107.0a1.en-US.win64.installer.exe
-
run the browser, open "about:support" into a new tab and maximize the window.
-
use autoscroll to scroll down the page, should be very smooth.
-
update nightly to the problematic build https://archive.mozilla.org/pub/firefox/nightly/2022/09/2022-09-23-21-21-51-mozilla-central/firefox-107.0a1.en-US.win64.installer.exe
-
run the browser, open "about:support" into a new tab and maximize the window.
-
use autoscroll to scroll down the page
Actual results:
actual result: scrolling is very jerky and overall video performance is bad.
**** more observations:
performance improves if window's width is reduced.
unticking "Use hardware acceleration when available" makes it a little better but it still can't deliver 60fps.
build 2022-09-23-09-30-59 autoscrolls at 60fps even with disabled hardware acceleration.
latest nightly 108.0 (2022-10-31) and beta 107.0b7 are also affected by this issue.
Expected results:
expected result: scrolling should be very smooth
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•3 years ago
|
||
Thanks for reporting. It's great that you've narrowed down the build with the poor performance. We have a tool called mozregression which can go a step further and find the specific bundle of code that is causing the performance problem on your system. Would you please try it out and report the results here?
Also, please attach to this Bug the text from the "Graphics" section of "about:support". And update your Intel graphics driver, if you haven't already.
here is mozregression 4.0.15 result (5.x mozregression wasn't working, error for python310.dll)
2022-11-02T02:02:49.439000: INFO : Narrowed integration regression window from [ba49c050, 61cde6b6] (4 builds) to [dd74d415, 61cde6b6] (2 builds) (~1 steps left)
2022-11-02T02:02:49.455000: DEBUG : Starting merge handling...
2022-11-02T02:02:49.455000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=61cde6b6f2737eee00c49fb75390aff3d814f677&full=1
2022-11-02T02:02:49.455000: DEBUG : redo: attempt 1/3
2022-11-02T02:02:49.455000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=61cde6b6f2737eee00c49fb75390aff3d814f677&full=1',), kwargs: {}, attempt #1
2022-11-02T02:02:49.455000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2022-11-02T02:02:50.999000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=61cde6b6f2737eee00c49fb75390aff3d814f677&full=1 HTTP/1.1" 200 None
2022-11-02T02:02:50.999000: DEBUG : Found commit message:
Bug 1789168 - Use modern flexbox emulation in the main browser area. r=Gijs
Now that DevTools splitters work this should be doable.
Differential Revision: https://phabricator.services.mozilla.com/D156385
2022-11-02T02:02:50.999000: DEBUG : Did not find a branch, checking all integration branches
2022-11-02T02:02:51.015000: INFO : The bisection is done.
2022-11-02T02:02:51.015000: INFO : Stopped
"Graphics" section of "about:support".
Graphics
Features
Compositing WebRender
Asynchronous Pan/Zoom wheel input enabled; scrollbar drag enabled; keyboard enabled; autoscroll enabled; smooth pinch-zoom enabled
WebGL 1 Driver WSI Info EGL_VENDOR: Google Inc. (Intel)
EGL_VERSION: 1.5 (ANGLE 2.1.15728 git hash: 6a5622459d2c)
EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_display_semaphore_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled EGL_ANDROID_blob_cache EGL_ANDROID_recordable EGL_ANGLE_image_d3d11_texture EGL_ANGLE_create_context_backwards_compatible EGL_KHR_create_context_no_error EGL_KHR_reusable_sync
EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_device_query EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_ANGLE_explicit_context EGL_ANGLE_feature_control
IsWebglOutOfProcessEnabled: 1
WebGL 1 Driver Renderer Google Inc. (Intel) -- ANGLE (Intel, Intel(R) HD Graphics Direct3D11 vs_4_1 ps_4_1, D3D11-9.17.10.4229)
WebGL 1 Driver Version OpenGL ES 2.0.0 (ANGLE 2.1.15728 git hash: 6a5622459d2c)
WebGL 1 Driver Extensions GL_ANGLE_base_vertex_base_instance GL_ANGLE_client_arrays GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_get_serialized_context_string GL_ANGLE_get_tex_level_parameter GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_memory_size GL_ANGLE_multi_draw GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_provoking_vertex GL_ANGLE_request_extension GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_color_buffer_float_rgb GL_CHROMIUM_color_buffer_float_rgba GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_lose_context GL_CHROMIUM_sync_query GL_EXT_EGL_image_external_wrap_modes GL_EXT_blend_func_extended GL_EXT_blend_minmax GL_EXT_color_buffer_half_float GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_draw_elements_base_vertex GL_EXT_float_blend GL_EXT_frag_depth GL_EXT_instanced_arrays GL_EXT_map_buffer_range GL_EXT_multisampled_render_to_texture GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_KHR_no_error GL_KHR_parallel_shader_compile GL_KHR_robust_buffer_access_behavior GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_compressed_EAC_R11_signed_texture GL_OES_compressed_EAC_R11_unsigned_texture GL_OES_compressed_EAC_RG11_signed_texture GL_OES_compressed_EAC_RG11_unsigned_texture GL_OES_compressed_ETC2_RGB8_texture GL_OES_compressed_ETC2_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture GL_OES_compressed_ETC2_sRGB8_alpha8_texture GL_OES_compressed_ETC2_sRGB8_texture GL_OES_depth24 GL_OES_depth32 GL_OES_draw_elements_base_vertex GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_border_clamp GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_texture_stencil8 GL_OES_vertex_array_object GL_WEBGL_video_texture
WebGL 1 Extensions ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_half_float EXT_float_blend EXT_frag_depth EXT_shader_texture_lod EXT_sRGB EXT_texture_compression_rgtc EXT_texture_filter_anisotropic MOZ_debug OES_element_index_uint OES_fbo_render_mipmap OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object WEBGL_color_buffer_float WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context
WebGL 2 Driver WSI Info EGL_VENDOR: Google Inc. (Intel)
EGL_VERSION: 1.5 (ANGLE 2.1.15728 git hash: 6a5622459d2c)
EGL_EXTENSIONS: EGL_EXT_create_context_robustness EGL_ANGLE_d3d_share_handle_client_buffer EGL_ANGLE_d3d_texture_client_buffer EGL_ANGLE_surface_d3d_texture_2d_share_handle EGL_ANGLE_query_surface_pointer EGL_ANGLE_window_fixed_size EGL_ANGLE_keyed_mutex EGL_ANGLE_surface_orientation EGL_NV_post_sub_buffer EGL_KHR_create_context EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_get_all_proc_addresses EGL_KHR_stream EGL_KHR_stream_consumer_gltexture EGL_NV_stream_consumer_gltexture_yuv EGL_ANGLE_flexible_surface_compatibility EGL_ANGLE_stream_producer_d3d_texture EGL_ANGLE_create_context_webgl_compatibility EGL_CHROMIUM_create_context_bind_generates_resource EGL_EXT_pixel_format_float EGL_KHR_surfaceless_context EGL_ANGLE_display_texture_share_group EGL_ANGLE_display_semaphore_share_group EGL_ANGLE_create_context_client_arrays EGL_ANGLE_program_cache_control EGL_ANGLE_robust_resource_initialization EGL_ANGLE_create_context_extensions_enabled EGL_ANDROID_blob_cache EGL_ANDROID_recordable EGL_ANGLE_image_d3d11_texture EGL_ANGLE_create_context_backwards_compatible EGL_KHR_create_context_no_error EGL_KHR_reusable_sync
EGL_EXTENSIONS(nullptr): EGL_EXT_client_extensions EGL_EXT_device_query EGL_EXT_platform_base EGL_EXT_platform_device EGL_ANGLE_platform_angle EGL_ANGLE_platform_angle_d3d EGL_ANGLE_device_creation EGL_ANGLE_device_creation_d3d11 EGL_ANGLE_experimental_present_path EGL_KHR_client_get_all_proc_addresses EGL_KHR_debug EGL_ANGLE_explicit_context EGL_ANGLE_feature_control
IsWebglOutOfProcessEnabled: 1
WebGL 2 Driver Renderer Google Inc. (Intel) -- ANGLE (Intel, Intel(R) HD Graphics Direct3D11 vs_4_1 ps_4_1, D3D11-9.17.10.4229)
WebGL 2 Driver Version OpenGL ES 3.0.0 (ANGLE 2.1.15728 git hash: 6a5622459d2c)
WebGL 2 Driver Extensions GL_ANGLE_base_vertex_base_instance GL_ANGLE_client_arrays GL_ANGLE_copy_texture_3d GL_ANGLE_depth_texture GL_ANGLE_explicit_context GL_ANGLE_explicit_context_gles1 GL_ANGLE_framebuffer_blit GL_ANGLE_framebuffer_multisample GL_ANGLE_get_serialized_context_string GL_ANGLE_get_tex_level_parameter GL_ANGLE_instanced_arrays GL_ANGLE_lossy_etc_decode GL_ANGLE_memory_size GL_ANGLE_multi_draw GL_ANGLE_pack_reverse_row_order GL_ANGLE_program_cache_control GL_ANGLE_provoking_vertex GL_ANGLE_request_extension GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ANGLE_texture_multisample GL_ANGLE_texture_usage GL_ANGLE_translated_shader_source GL_CHROMIUM_bind_generates_resource GL_CHROMIUM_bind_uniform_location GL_CHROMIUM_copy_compressed_texture GL_CHROMIUM_copy_texture GL_CHROMIUM_lose_context GL_CHROMIUM_sync_query GL_EXT_EGL_image_external_wrap_modes GL_EXT_blend_func_extended GL_EXT_blend_minmax GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers GL_EXT_draw_buffers_indexed GL_EXT_draw_elements_base_vertex GL_EXT_float_blend GL_EXT_frag_depth GL_EXT_instanced_arrays GL_EXT_map_buffer_range GL_EXT_multisampled_render_to_texture GL_EXT_occlusion_query_boolean GL_EXT_read_format_bgra GL_EXT_robustness GL_EXT_sRGB GL_EXT_shader_texture_lod GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_compression_s3tc_srgb GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA8888 GL_EXT_texture_norm16 GL_EXT_texture_rg GL_EXT_texture_storage GL_EXT_unpack_subimage GL_KHR_debug GL_KHR_no_error GL_KHR_parallel_shader_compile GL_KHR_robust_buffer_access_behavior GL_NV_EGL_stream_consumer_external GL_NV_fence GL_NV_pack_subimage GL_NV_pixel_buffer_object GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_compressed_EAC_R11_signed_texture GL_OES_compressed_EAC_R11_unsigned_texture GL_OES_compressed_EAC_RG11_signed_texture GL_OES_compressed_EAC_RG11_unsigned_texture GL_OES_compressed_ETC2_RGB8_texture GL_OES_compressed_ETC2_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_RGBA8_texture GL_OES_compressed_ETC2_punchthroughA_sRGB8_alpha_texture GL_OES_compressed_ETC2_sRGB8_alpha8_texture GL_OES_compressed_ETC2_sRGB8_texture GL_OES_depth24 GL_OES_depth32 GL_OES_draw_buffers_indexed GL_OES_draw_elements_base_vertex GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_border_clamp GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_texture_stencil8 GL_OES_vertex_array_object GL_WEBGL_video_texture
WebGL 2 Extensions EXT_color_buffer_float EXT_float_blend EXT_texture_compression_rgtc EXT_texture_filter_anisotropic MOZ_debug OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_lose_context
Direct2D true
Target Frame Rate 60
DirectWrite true (6.2.9200.23480)
GPU #1
Active Yes
Description Intel(R) HD Graphics
Vendor ID 0x8086
Device ID 0x0102
Driver Version 9.17.10.4229
Driver Date 5-26-2015
Drivers igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
Subsys ID 2abf103c
RAM 0
GPU #2
Active No
RAM 0
Diagnostics
AzureCanvasBackend direct2d 1.1
AzureCanvasBackend (UI Process) skia
AzureContentBackend skia
AzureContentBackend (UI Process) skia
AzureFallbackCanvasBackend (UI Process) skia
CMSOutputProfile AAAMSExpbm8CEAAAbW50clJHQiBYWVogB84AAgAJAAYAMQAAYWNzcE1TRlQAAAAASUVDIHNSR0IAAAAAAAAAAAAAAAAAAPbWAAEAAAAA0y1IUCAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARY3BydAAAAVAAAAAzZGVzYwAAAYQAAABsd3RwdAAAAfAAAAAUYmtwdAAAAgQAAAAUclhZWgAAAhgAAAAUZ1hZWgAAAiwAAAAUYlhZWgAAAkAAAAAUZG1uZAAAAlQAAABwZG1kZAAAAsQAAACIdnVlZAAAA0wAAACGdmlldwAAA9QAAAAkbHVtaQAAA/gAAAAUbWVhcwAABAwAAAAkdGVjaAAABDAAAAAMclRSQwAABDwAAAgMZ1RSQwAABDwAAAgMYlRSQwAABDwAAAgMdGV4dAAAAABDb3B5cmlnaHQgKGMpIDE5OTggSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkAAGRlc2MAAAAAAAAAEnNSR0IgSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAADzUQABAAAAARbMWFlaIAAAAAAAAAAAAAAAAAAAAABYWVogAAAAAAAAb6IAADj1AAADkFhZWiAAAAAAAABimQAAt4UAABjaWFlaIAAAAAAAACSgAAAPhAAAts9kZXNjAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAABZJRUMgaHR0cDovL3d3dy5pZWMuY2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZGVzYwAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAuSUVDIDYxOTY2LTIuMSBEZWZhdWx0IFJHQiBjb2xvdXIgc3BhY2UgLSBzUkdCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB2aWV3AAAAAAATpP4AFF8uABDPFAAD7cwABBMLAANcngAAAAFYWVogAAAAAABMCVYAUAAAAFcf521lYXMAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAKPAAAAAnNpZyAAAAAAQ1JUIGN1cnYAAAAAAAAEAAAAAAUACgAPABQAGQAeACMAKAAtADIANwA7AEAARQBKAE8AVABZAF4AYwBoAG0AcgB3AHwAgQCGAIsAkACVAJoAnwCkAKkArgCyALcAvADBAMYAywDQANUA2wDgAOUA6wDwAPYA+wEBAQcBDQETARkBHwElASsBMgE4AT4BRQFMAVIBWQFgAWcBbgF1AXwBgwGLAZIBmgGhAakBsQG5AcEByQHRAdkB4QHpAfIB+gIDAgwCFAIdAiYCLwI4AkECSwJUAl0CZwJxAnoChAKOApgCogKsArYCwQLLAtUC4ALrAvUDAAMLAxYDIQMtAzgDQwNPA1oDZgNyA34DigOWA6IDrgO6A8cD0wPgA+wD+QQGBBMEIAQtBDsESARVBGMEcQR+BIwEmgSoBLYExATTBOEE8AT+BQ0FHAUrBToFSQVYBWcFdwWGBZYFpgW1BcUF1QXlBfYGBgYWBicGNwZIBlkGagZ7BowGnQavBsAG0QbjBvUHBwcZBysHPQdPB2EHdAeGB5kHrAe/B9IH5Qf4CAsIHwgyCEYIWghuCIIIlgiqCL4I0gjnCPsJEAklCToJTwlkCXkJjwmkCboJzwnlCfsKEQonCj0KVApqCoEKmAquCsUK3ArzCwsLIgs5C1ELaQuAC5gLsAvIC+EL+QwSDCoMQwxcDHUMjgynDMAM2QzzDQ0NJg1ADVoNdA2ODakNww3eDfgOEw4uDkkOZA5/DpsOtg7SDu4PCQ8lD0EPXg96D5YPsw/PD+wQCRAmEEMQYRB+EJsQuRDXEPURExExEU8RbRGMEaoRyRHoEgcSJhJFEmQShBKjEsMS4xMDEyMTQxNjE4MTpBPFE+UUBhQnFEkUahSLFK0UzhTwFRIVNBVWFXgVmxW9FeAWAxYmFkkWbBaPFrIW1hb6Fx0XQRdlF4kXrhfSF/cYGxhAGGUYihivGNUY+hkgGUUZaxmRGbcZ3RoEGioaURp3Gp4axRrsGxQbOxtjG4obshvaHAIcKhxSHHscoxzMHPUdHh1HHXAdmR3DHeweFh5AHmoelB6+HukfEx8+H2kflB+/H+ogFSBBIGwgmCDEIPAhHCFIIXUhoSHOIfsiJyJVIoIiryLdIwojOCNmI5QjwiPwJB8kTSR8JKsk2iUJJTglaCWXJccl9yYnJlcmhya3JugnGCdJJ3onqyfcKA0oPyhxKKIo1CkGKTgpaymdKdAqAio1KmgqmyrPKwIrNitpK50r0SwFLDksbiyiLNctDC1BLXYtqy3hLhYuTC6CLrcu7i8kL1ovkS/HL/4wNTBsMKQw2zESMUoxgjG6MfIyKjJjMpsy1DMNM0YzfzO4M/E0KzRlNJ402DUTNU01hzXCNf02NzZyNq426TckN2A3nDfXOBQ4UDiMOMg5BTlCOX85vDn5OjY6dDqyOu87LTtrO6o76DwnPGU8pDzjPSI9YT2hPeA+ID5gPqA+4D8hP2E/oj/iQCNAZECmQOdBKUFqQaxB7kIwQnJCtUL3QzpDfUPARANER0SKRM5FEkVVRZpF3kYiRmdGq0bwRzVHe0fASAVIS0iRSNdJHUljSalJ8Eo3Sn1KxEsMS1NLmkviTCpMcky6TQJNSk2TTdxOJU5uTrdPAE9JT5NP3VAnUHFQu1EGUVBRm1HmUjFSfFLHUxNTX1OqU/ZUQlSPVNtVKFV1VcJWD1ZcVqlW91dEV5JX4FgvWH1Yy1kaWWlZuFoHWlZaplr1W0VblVvlXDVchlzWXSddeF3JXhpebF69Xw9fYV+zYAVgV2CqYPxhT2GiYfViSWKcYvBjQ2OXY+tkQGSUZOllPWWSZedmPWaSZuhnPWeTZ+loP2iWaOxpQ2maafFqSGqfavdrT2una/9sV2yvbQhtYG25bhJua27Ebx5veG/RcCtwhnDgcTpxlXHwcktypnMBc11zuHQUdHB0zHUodYV14XY+dpt2+HdWd7N4EXhueMx5KnmJeed6RnqlewR7Y3vCfCF8gXzhfUF9oX4BfmJ+wn8jf4R/5YBHgKiBCoFrgc2CMIKSgvSDV4O6hB2EgITjhUeFq4YOhnKG14c7h5+IBIhpiM6JM4mZif6KZIrKizCLlov8jGOMyo0xjZiN/45mjs6PNo+ekAaQbpDWkT+RqJIRknqS45NNk7aUIJSKlPSVX5XJljSWn5cKl3WX4JhMmLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf//
Display0 1920x1080@60Hz scales:1.000000|1.000000
DisplayCount 1
HardwareStretching both=0 window-only=0 full-screen-only=0 none=0 error=1
GPUProcessPid 2900
GPUProcess
Device Reset
ClearType Parameters Gamma: 2.2 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 300
Decision Log
HW_COMPOSITING
available by default
D3D11_COMPOSITING
available by default
DIRECT2D
available by default
D3D11_HW_ANGLE
available by default
GPU_PROCESS
available by default
WEBRENDER
available by default
WEBRENDER_QUALIFIED
available by default
WEBRENDER_COMPOSITOR
available by default
unavailable by runtime: No DirectComposition usage
WEBRENDER_PARTIAL
available by default
WEBRENDER_SHADER_CACHE
available by default
WEBRENDER_OPTIMIZED_SHADERS
available by default
WEBRENDER_ANGLE
available by default
WEBRENDER_DCOMP_PRESENT
available by default
unavailable by env: Requires Windows 10 or later
WEBRENDER_SOFTWARE
available by default
WEBGPU
disabled by default: Disabled by default
WINDOW_OCCLUSION
available by default
VP8_HW_DECODE
available by default
VP9_HW_DECODE
available by default
REUSE_DECODER_DEVICE
available by default
BACKDROP_FILTER
available by default
Blocklisted due to known issues: bug 1785366
Comment 4•3 years ago
|
||
Thank you. Your driver is from 2015. Please try to update it, and if the problem is still happening, please post the updated text from the "Graphics" section of about:support.
Meanwhile, the regression result points to Bug 1789168.
Comment 5•3 years ago
|
||
Hmm... actually looks like what you have installed is the last driver for Intel HD Graphics 2000. We'll see if we can get performance improved for your case.
Updated•3 years ago
|
Comment 6•3 years ago
|
||
:emilio, since you are the author of the regressor, bug 1789168, could you take a look? Also, could you set the severity field?
For more information, please visit auto_nag documentation.
| Assignee | ||
Comment 7•3 years ago
|
||
I'm quite confused as to how that patch could ever regress video playback / scrolling performance, since all that is in a separate process altogether... The only remotely feasible explanation is that we come up with slightly different subpixel values for the web content area and that somehow makes your GPU or WebRender trip, but that's fairly unlikely...
Some questions:
- What's your Windows scaling settings / DPI? If you open a console with F12 and type
window.devicePixelRatio, what value do you get back? - Any other "interesting" bits on your setup? High refresh-rate monitor or what not?
- If my hypothesis above is correct, bug 1792285 probably helped here... Is latest nightly any better?
- Is there any chance you could take a profile on a bad and good build on your machine to see what might be going on? Please choose the Graphics preset, there are some docs here on how to do that...
- Also you mention that disabling HW acceleration is better on your machine after the regression than HW acceleration enabled... How does pre/post-regression behavior compare with WH acceleration disabled?
Thanks, and sorry for all the questions, I'm fairly surprised about this regression!
Comment 8•3 years ago
|
||
This appears to be a scrolling performance issue, not a video playback performance issue.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)
Some questions:
What's your Windows scaling settings / DPI?
Scaling is set to smaller 100% (default)
DPI 100% "9 point Segoe UI at 96 pixels per inch"
If you open a console with F12 and type window.devicePixelRatio, what value do you get back?
It returns "1"
Any other "interesting" bits on your setup?
I have custom clear type settings, firefox detects those under about:support ClearType Parameters Gamma: 2.2 Pixel Structure: RGB ClearType Level: 100 Enhanced Contrast: 300
I have a few visual effects disabled under System Properties -> Advanced -> Performance settings
I messed with the above settings but I didn't see any change pre/post regression.
High refresh-rate monitor or what not?
I have a standard 60Hz full hd screen
If my hypothesis above is correct, bug 1792285 probably helped here... Is latest nightly any better?
I tested 2022-10-02 and I didn't see any improvement.
Is there any chance you could take a profile on a bad and good build on your machine to see what might be going on? Please choose the Graphics preset, there are some docs here on how to do that...
you mean https://profiler.firefox.com/ if so I'll have a look at that.
Also you mention that disabling HW acceleration is better on your machine after the regression than HW acceleration enabled...
it is slightly better but the performance drop is still very noticeable.
How does pre/post-regression behavior compare with WH acceleration disabled?
I don't see any performance drop on pre-regression with hw acceleration disabled
I still have performance issue on post-regression with hw acceleration disabled
Thanks, and sorry for all the questions, I'm fairly surprised about this regression!
| Reporter | ||
Comment 10•3 years ago
|
||
here are two profiles pre/post regression where I use autoscroll for moving down "about:support" page
pre-regression https://share.firefox.dev/3DAHHuh
post-regression https://share.firefox.dev/3fpOv5T
hope this helps somehow and thanks for looking into this!
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 11•3 years ago
|
||
Using comparable time slices: pre-regression / post-regression. You can see in the profile that scroll events after the regression arrive a lot slower. But still everything seems mostly idle, I'm still not quite sure how my patch can cause it... Another couple questions, just to confirm (thanks for bearing with me):
- Is this specific to auto-scrolling, or does it also happen with trackpad scroll / mousewheel, etc?
- Does this happen only on parent-process pages (like about:support), or also on other pages like this one?
| Assignee | ||
Comment 12•3 years ago
|
||
Markus / Jeff, is there any chance I could nerd-snipe you into looking at the profiles in comment 11, just to confirm my current theory? No worries if not.
It seems like in the post-regression commit, there are slower composites. In the "renderer" thread I see that there's a "fast" composite (under 6ms) then a slow one that potentially cause us to miss frames (over 14ms). My theory is that those missing frames are what cause the reported issue here.
However it's hard to know what the root cause of that really is off-hand, it seems rather weird that my patch would've caused it, and the symbols during those composite don't seem right... I'm starting to guess something like this may be the culprit (now we have a lot more pseudo-stacking-contexts in our UI I guess?). But that's kind of a long shot, and without symbols it's not easy to confirm... Plus I don't think display lists should be too different given we should hit this...
| Assignee | ||
Comment 13•3 years ago
|
||
No need to be an out of band member function given the only callers are
in flex / grid code.
I was looking at this in the context of bug 1798396. This probably
doesn't matter for PGO, but it being a static method helps reason about
the flags being the same for all items.
Updated•3 years ago
|
Comment 14•3 years ago
|
||
Comment on attachment 9301691 [details]
Bug 1798396 - Clean up DisplayFlagForFlexOrGridItem. r=#layout,TYLin
Revision D161102 was moved to bug 1798830. Setting attachment 9301691 [details] to obsolete.
| Assignee | ||
Comment 15•3 years ago
|
||
Err, sorry for the noise.
| Assignee | ||
Comment 16•3 years ago
|
||
Shot in the dark for now, no measurable perf impact here...
| Assignee | ||
Comment 17•3 years ago
|
||
The findbar is the only content in that region that is a bit suspect as
well, and visibility: collapse might be doing something that trips WR or
APZ. Try to get rid of it more aggressively.
This is not landable as-is because it breaks the animation.
| Assignee | ||
Comment 18•3 years ago
|
||
Kinda building on the above hypothesis.
| Assignee | ||
Comment 19•3 years ago
|
||
Any chance you could check if the build here fixes it for you? It has the patches above.
| Reporter | ||
Comment 20•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
- Is this specific to auto-scrolling, or does it also happen with trackpad scroll / mousewheel, etc?
it happens with mouse wheel too.- Does this happen only on parent-process pages (like about:support), or also on other pages like this one?
scrolling this page does the same.
This "lack of smoothness" kicks in if firefox window takes all/most of my screen, eveything is OK if I reduce the window to say 1/4 of my screen.
pre-regression I could watch youtube full screen vp9/360p/30fps without problems while post-regression video stutters.
How can I try that build you made? I don't see any download link on that page, sorry.
meanwhile I tried to "heal" the post-regression by swapping some files from pre-regression and looks like browser\omni.ja (the ~40MB one into the subfolder) does it
hope this helps and thanks for helping me!
| Assignee | ||
Comment 21•3 years ago
|
||
For Windows x64, this is the right link. Just unzip it somewhere and run the firefox.exe executable there.
| Reporter | ||
Comment 22•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #21)
For Windows x64, this is the right link. Just unzip it somewhere and run the
firefox.exeexecutable there.
I tried this build but I didn't see any improvement.
meanwhile I did some more messing around with omni.ja
unsurprisingly, mozregression did catch it, removing this part
#browser {
-moz-box-layout: flex;
}
from "chrome\browser\content\browser\browser.css" restored performance back to normal on my system.
Comment 23•3 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)
Using comparable time slices: pre-regression / post-regression. You can see in the profile that scroll events after the regression arrive a lot slower.
Whatever is happening seems to be slowing down vsync itself: https://share.firefox.dev/3hkuTkg
Maybe this happens if we give the DWM too much work. I can also see that the tasks on the Renderer thread take longer, though due to the bad symbols it's not 100% clear where the slow part is. It might be in the "WaitForGPU" sleep loop.
(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)
However it's hard to know what the root cause of that really is off-hand
Yeah, my first intuition was that something is throwing off WebRender's picture caching heuristics and we end up repainting too much. This could be confirmed by setting gfx.webrender.debug.picture-caching to true and checking if there's more "red" on the screen.
However, the NumDrawCalls and NumPictureCacheInvalidated markers on the Renderer thread don't really agree with this hypothesis. Those are 15/1 before and 13/1 after. So there is a difference, but it's going in an unexpected direction. I'm not sure what to make of that.
it seems rather weird that my patch would've caused it,
The picture caching heuristics definitely look at stacking contexts. If the display list looks different before/after, it could affect them.
and the symbols during those composite don't seem right...
It looks like we never upload symbols from autoland builds. I went to the treeherder pushes for the two builds, but the upload-symbols jobs aren't available at all on that tree, it looks like. You could get symbols by re-pushing these changesets to try and uploading symbols for those try builds.
I'm starting to guess something like this may be the culprit (now we have a lot more pseudo-stacking-contexts in our UI I guess?). But that's kind of a long shot, and without symbols it's not easy to confirm... Plus I don't think display lists should be too different given we should hit this...
We could compare display lists before / after, with the layout.display-list.dump-parent pref.
Comment 24•3 years ago
|
||
The severity field is not set for this bug.
:bhood, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•3 years ago
|
Comment 25•3 years ago
|
||
Set release status flags based on info from the regressing bug 1789168
Updated•3 years ago
|
Updated•3 years ago
|
Comment 26•3 years ago
|
||
Hi, I've also observed the same behavior on a Windows 7 desktop system and arrived at the following conclusions after doing some testing:
- this is a Windows-only bug and is most likely limited to Windows 7 since Windows 8 and later do not implement DWM blur;
- this bug is related to Windows' Desktop Window Manager (DWM), but it is not an OS bug, and also is not a display driver bug;
- this bug is a regression that was introduced in commit 61cde6b6f2737eee00c49fb75390aff3d814f677 [1];
- hardware acceleration within Firefox is largely irrelevant to this issue, although it may influence the GPU's power saving state and hence lead to a smaller framerate drop.
The bug occurs because Firefox instructs DWM via DwmExtendFrameIntoClientArea[2] to render the entire window as a translucent sheet of glass, as opposed to just the frame borders as would typically be expected with opaque inner content. Framerates are then reduced due to DWM having to apply blur to a much larger area. Overdraw also occurs, but its impact is less than that of DWM suddenly needing to blur an unusually large region of the screen.
The impact is especially significant if the GPU is in low power mode and/or if there are many (>10?) stacked windows, whether Firefox's own or otherwise (naturally, Firefox's windows will be comparatively "heavier" than others due to this bug).
Typically, Firefox determines which of its window zones are obscured by content ("opaque") and adjusts its call to DwmExtendFrameIntoClientArea (see [3]). Prior to the aforementioned commit, Firefox was able to (correctly) conclude that the center of its window was opaque (see [4]), but that has since become regressed (see [5]). For context, the output was generated by a hook DLL injected via the AppInit_DLLs registry entry, but monitoring can, of course, also be performed by instrumenting the methods in question to add debug output and recompiling. It's worth noting that the API gets called for other windows as well (e.g. browser action popups), but such calls are made with 0,0,0,0 bounds and are therefore irrelevant.
Given that removing the -moz-box-layout: flex; rule immediately returns the browser to its opaque form (as illustrated in [4] and [5]), it should be safe to assume that the aforementioned opaque region detection code remains functional. Perhaps it needs to be adjusted to recognize modern flexbox?
Hopefully, this provides some background context for why the issue occurs. :)
Additional details:
Entering "Customize Toolbar..." mode also causes the browser to turn translucent, but this behavior already occurs prior to the regressing commit, and it also reverts when leaving customize mode (unless blocked by this bug, in which case it never reverts to opaque). I do not know whether that (i.e. turning translucent) is expected behavior.
Testing this without instrumentation may be tricky due to the opaque region detection code, which leads to a Schrödinger's cat-esque situation since any CSS-based attempt to peek behind the opaque inner content leads to the window being made translucent. However, one convenient way to determine whether a window is in the translucent, "sheet of glass" -1,-1,-1,-1 form is to look at its left or right borders, down ~25% from the top of the window. Regular, "opaque" windows will have a little "shine" effect while the window has focus. If a window is translucent or has lost focus, this shine effect will be missing from the borders. Said window should be positioned atop a dark background so that the shine effect can be seen.
To clarify, this shine effect will only be visible if both of the following conditions are met:
- the window is currently in focus; and
- the window is not in the translucent, sheet of glass form.
[3]: (the following reads like a callstack)
https://hg.mozilla.org/mozilla-central/file/61cde6b6f2737eee00c49fb75390aff3d814f677/widget/windows/nsWindow.cpp#l3448
https://hg.mozilla.org/mozilla-central/file/61cde6b6f2737eee00c49fb75390aff3d814f677/widget/windows/nsWindow.cpp#l3396
https://hg.mozilla.org/mozilla-central/file/61cde6b6f2737eee00c49fb75390aff3d814f677/layout/base/nsLayoutUtils.cpp#l3498
https://hg.mozilla.org/mozilla-central/file/61cde6b6f2737eee00c49fb75390aff3d814f677/layout/painting/nsDisplayList.h#l1481
https://hg.mozilla.org/mozilla-central/file/61cde6b6f2737eee00c49fb75390aff3d814f677/gfx/layers/wr/WebRenderCommandBuilder.cpp#l1984
[4]: Normal, expected output from df40645f791d0cb16c25d254c6bea3f077370472 (2022-09-23-09-30-59-mozilla-central):
Note: LRTB = left right top bottom in pixels, respectively
(browser startup, hook DLL attaches)
Attached: R:\core\firefox.exe (after dwmapi.dll)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: 2 2 2 2})
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: 2 2 107 2})
(entered "Customize Toolbar..." mode; browser leaves its opaque form)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: -1 -1 -1 -1})
(exited "Customize Toolbar..." mode; browser returns to its opaque form)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: 2 2 106 2})
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: 2 2 107 2})
(maximized window)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: 2 2 106 2})
(restored window, i.e. unmaximized)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: 2 2 107 2})
(no change when opening/closing the findbar)
(added the `-moz-box-layout: flex;` rule to `html#main-window > body > hbox#browser` using the Browser Toolbox)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: -1 -1 -1 -1})
(removed the rule again)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00240920, {LRTB: 2 2 107 2})
[5]: Bugged output from 12300304d39453250dfdaa8e249056659a20adbc (2022-09-23-21-21-51-mozilla-central):
(browser startup, hook DLL attaches)
Attached: R:\core\firefox.exe (after dwmapi.dll)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x002104D4, {LRTB: 2 2 2 2})
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x002104D4, {LRTB: -1 -1 -1 -1})
(no relevant subsequent output since the browser never reverts to its opaque form)
(unticking the `-moz-box-layout: flex;` rule on `html#main-window > body > hbox#browser` using the Browser Toolbox)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x002104D4, {LRTB: 2 2 107 2})
(ticking the same rule again)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x002104D4, {LRTB: -1 -1 -1 -1})
| Assignee | ||
Comment 27•3 years ago
|
||
Thanks, that's awesome information, let me poke at how we compute the glass area.
| Assignee | ||
Comment 28•3 years ago
|
||
Updated•3 years ago
|
| Assignee | ||
Comment 29•3 years ago
|
||
This we don't need to uplift.
Depends on D162534
Comment 30•3 years ago
|
||
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 31•3 years ago
|
||
Comment on attachment 9304410 [details]
Bug 1798396 - Move win-exclude-glass region handling to work with non-xul-box frames. r=mstange,tnikkel
Beta/Release Uplift Approval Request
- User impact if declined: Windows 7 performance with the Aero theme is suboptimal.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: If QA could repro this and verify the fix, it'd be ideal.
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Pretty straight-forward refactoring.
- String changes made/needed: none
- Is Android affected?: No
| Assignee | ||
Updated•3 years ago
|
Comment 32•3 years ago
|
||
| bugherder | ||
Updated•3 years ago
|
Comment 33•3 years ago
|
||
In a few hours we should have a new nightly, do you mind verifying if that corrects the issue?
Updated•3 years ago
|
Comment 34•3 years ago
|
||
I was able to reproduce the issue with Firefox Nightly 107.0a1 (2022-09-23) on Windows 7 by following the infos provided in Comment 0.
GPU used - Intel HD Graphics 530, with driver version: 21.20.16.5174
The issue is fixed on Firefox Nightly 109.0a1 (2022-09-21), and the performance while autoscrolling through about:support is as good as in the latest good build provided in Comment 0.
Comment 35•3 years ago
|
||
| Reporter | ||
Comment 36•3 years ago
|
||
I can confirm the issue is fixed in latest nightly 2022-11-22.
thanks Emilio :)
Comment 37•3 years ago
|
||
Comment on attachment 9304410 [details]
Bug 1798396 - Move win-exclude-glass region handling to work with non-xul-box frames. r=mstange,tnikkel
Approved for 108.0b5
Comment 38•3 years ago
|
||
| bugherder uplift | ||
Comment 39•3 years ago
|
||
Updated•3 years ago
|
Comment 40•3 years ago
|
||
| bugherder | ||
Comment 41•3 years ago
|
||
Verified the fix with Firefox 108.0b5 as well and the autoscrolling in about:support page is smooth.
| Assignee | ||
Comment 42•3 years ago
|
||
Comment on attachment 9304410 [details]
Bug 1798396 - Move win-exclude-glass region handling to work with non-xul-box frames. r=mstange,tnikkel
Beta/Release Uplift Approval Request
- User impact if declined: Significant performance degradation in windows 7
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: see above.
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Straight-forward refactoring.
- String changes made/needed: none
- Is Android affected?: No
| Assignee | ||
Updated•3 years ago
|
Comment 44•3 years ago
|
||
Comment on attachment 9304410 [details]
Bug 1798396 - Move win-exclude-glass region handling to work with non-xul-box frames. r=mstange,tnikkel
108 goes to RC on Monday 2022-11-05. There's no 107 release planned before then.
Comment 45•3 years ago
|
||
Removing the qe-verify+ flag as this was verified on Beta 108 and Nightly 109.
Comment 46•3 years ago
|
||
<spamyourwhateverhere@outlook.com> was not able to comment on the ticket but replied the following:
I have tested both the x86-32 and x86-64 builds locally, and they seem to be working correctly.
Output from a29b80b107103df84e493008e420e30aea857da1 (2022-11-21-15-38-27-mozilla-central):
x86-32
(browser startup, hook DLL attaches)
Attached: R:\core\firefox.exe (after dwmapi.dll)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: 2 2 2 2})
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: 2 2 107 2})
(entered "Customize Toolbar..." mode; browser leaves its opaque form)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: -1 -1 -1 -1})
(exited "Customize Toolbar..." mode; browser returns to its opaque form)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: 2 2 106 2})
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: 2 2 107 2})
(maximized window)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: 2 2 106 2})
(restored window, i.e. unmaximized)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: 2 2 107 2})
(no change when opening/closing the findbar)
(added a `opacity: 0;` rule on `html#main-window > body > hbox#browser` using the Browser Toolbox to manually force translucency, since the `-moz-box-layout: flex;` rule has already been moved to `html#main-window`; context: https://hg.mozilla.org/mozilla-central/rev/aa325161aae5e555cab4d44b6662bbe029d26a5d )
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: -1 -1 -1 -1})
(removed the opacity rule again)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x001D0E8A, {LRTB: 2 2 107 2})
(no relevant changes occurred when unticking/ticking the `-moz-box-layout: flex;` rule on `html#main-window`, although `DwmExtendFrameIntoClientArea` did get called with `0,0,0,0` bounds for 3 other unknown windows)
x86-64
(browser startup, hook DLL attaches)
Attached: R:\core\firefox.exe (after dwmapi.dll)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: 2 2 2 2})
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: 2 2 107 2})
(entered "Customize Toolbar..." mode; browser leaves its opaque form)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: -1 -1 -1 -1})
(exited "Customize Toolbar..." mode; browser returns to its opaque form)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: 2 2 106 2})
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: 2 2 107 2})
(maximized window)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: 2 2 106 2})
(restored window, i.e. unmaximized)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: 2 2 107 2})
(no change when opening/closing the findbar)
(added a `opacity: 0;` rule on `html#main-window > body > hbox#browser` using the Browser Toolbox to manually force translucency)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: -1 -1 -1 -1})
(removed the opacity rule again)
R:\core\firefox.exe : dwmapi!DwmExtendFrameIntoClientArea(0x00000000001E0EA4, {LRTB: 2 2 107 2})
(no relevant changes occurred when unticking/ticking the `-moz-box-layout: flex;` rule on `html#main-window`, although `DwmExtendFrameIntoClientArea` did get called with `0,0,0,0` bounds for 2 other unknown windows)
Conclusion: The regression is fixed, and the opaque region detection code appears to be working properly. The entire window was correctly blurred as expected when hbox#browser was made transparent.
Description
•