(In reply to Robbie Khan from comment #13) > Sure please see here: > https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link > (I don't see an option in the message box here to attach so Gdrive link instead) Thanks again! You can add attachments from the attachments lists at the top of the page, it is a separate concept from comments in Bugzilla. Below are some more potential clues (with the help of :florian). Your screen refresh rate of 240 Hz should explain why the issue has such a big impact with your configuration. It can explain why Firefox issues the `DwmFlush` at an interval of 4ms rather than something else. You should be able to limit the impact of the issue by lowering it the refresh rate in Windows if needed. Can you confirm the impact of using a more standard refresh rate of, say, 60 Hz? Another non-standard thing is that you are using Magnifier, which uses Firefox's accessibility API. This appears in the performance profile you recorded, in the Privileged Content process's markers. The accessibility notifications appear as a RefreshObserver and the first RefreshDriverTick shows "Tick Reason: HasObservers", so, this might be what starts the cycle. Can you confirm if the issue also occurs with Magnifier closed? (In reply to Robbie Khan from comment #14) > I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case. It is correct that it seems not to have any big impact as far as I can tell (because the impact seems to correlate more with Firefox's usage of `DwmFlush`), but it can add noise that can disturb the investigation, especially because it directly interacts with DWM too. The closer we are to a standard configuration in the recordings while still reproducing the bug, the more solid our conclusions will be.
Bug 1924932 Comment 15 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Robbie Khan from comment #13) > Sure please see here: > https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link > (I don't see an option in the message box here to attach so Gdrive link instead) Thanks again! You can add attachments from the attachments lists at the top of the page, it is a separate concept from comments in Bugzilla. Below are some more potential clues (with the help of :florian). Your screen refresh rate of 240 Hz should explain why the issue has such a big impact with your configuration. It can explain why Firefox triggers the `DwmFlush` at an interval of 4ms rather than something else. You should be able to limit the impact of the issue by lowering it the refresh rate in Windows if needed. Can you confirm the impact of using a more standard refresh rate of, say, 60 Hz? Another non-standard thing is that you are using Magnifier, which uses Firefox's accessibility API. This appears in the performance profile you recorded, in the Privileged Content process's markers. The accessibility notifications appear as a RefreshObserver and the first RefreshDriverTick shows "Tick Reason: HasObservers", so, this might be what starts the cycle. Can you confirm if the issue also occurs with Magnifier closed? (In reply to Robbie Khan from comment #14) > I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case. It is correct that it seems not to have any big impact as far as I can tell (because the impact seems to correlate more with Firefox's usage of `DwmFlush`), but it can add noise that can disturb the investigation, especially because it directly interacts with DWM too. The closer we are to a standard configuration in the recordings while still reproducing the bug, the more solid our conclusions will be.
(In reply to Robbie Khan from comment #13) > Sure please see here: > https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link > (I don't see an option in the message box here to attach so Gdrive link instead) Thanks again! You can add attachments from the attachments lists at the top of the page, it is a separate concept from comments in Bugzilla. Below are some more potential clues (with the help of :florian). Your screen refresh rate of 240 Hz should explain why the issue has such a big impact with your configuration. It can explain why Firefox triggers the `DwmFlush` at an interval of 4ms rather than something else. You should be able to limit the impact of the issue by lowering the refresh rate in Windows if needed. Can you confirm the impact of using a more standard refresh rate of, say, 60 Hz? Another non-standard thing is that you are using Magnifier, which uses Firefox's accessibility API. This appears in the performance profile you recorded, in the Privileged Content process's markers. The accessibility notifications appear as a RefreshObserver and the first RefreshDriverTick shows "Tick Reason: HasObservers", so, this might be what starts the cycle. Can you confirm if the issue also occurs with Magnifier closed? (In reply to Robbie Khan from comment #14) > I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case. It is correct that it seems not to have any big impact as far as I can tell (because the impact seems to correlate more with Firefox's usage of `DwmFlush`), but it can add noise that can disturb the investigation, especially because it directly interacts with DWM too. The closer we are to a standard configuration in the recordings while still reproducing the bug, the more solid our conclusions will be.
(In reply to Robbie Khan from comment #13) > Sure please see here: > https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link > (I don't see an option in the message box here to attach so Gdrive link instead) Thanks again! You can add attachments from the attachments lists at the top of the page, it is a separate concept from comments in Bugzilla. Below are some more potential clues (with the help of :florian). Your screen refresh rate of 240 Hz should explain why the issue has such a big impact with your configuration. It can explain why Firefox triggers the `DwmFlush` at an interval of 4ms rather than something else. You should be able to limit the impact of the issue by lowering the refresh rate in Windows if needed. Can you confirm the impact of using a more standard refresh rate of, say, 60 Hz? Another non-standard thing is that you are using Magnifier, which uses Firefox's accessibility API. This appears in the performance profiles you recorded, in the Privileged Content process's markers. The accessibility notifications appear there as a RefreshObserver and the first RefreshDriverTick shows "Tick Reason: HasObservers", so, this might be what starts the cycle. Can you confirm if the issue also occurs with Magnifier closed? (In reply to Robbie Khan from comment #14) > I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case. It is correct that it seems not to have any big impact as far as I can tell (because the impact seems to correlate more with Firefox's usage of `DwmFlush`), but it can add noise that can disturb the investigation, especially because it directly interacts with DWM too. The closer we are to a standard configuration in the recordings while still reproducing the bug, the more solid our conclusions will be.
(In reply to Robbie Khan from comment #13) > Sure please see here: > https://drive.google.com/file/d/1j1mEA54Y3K0xdcvTfBdz74_kKaYyZq9W/view?usp=drive_link > (I don't see an option in the message box here to attach so Gdrive link instead) Thanks again! You can add attachments from the attachments lists at the top of the page, it is a separate concept from comments in Bugzilla. Below are some more potential clues (with the help of :florian). Your screen refresh rate of 240 Hz should explain why the issue has such a big impact with your configuration. It can explain why Firefox triggers the `DwmFlush` at an interval of 4ms rather than something else. You should be able to limit the impact of the issue by lowering the refresh rate in Windows if needed. Can you confirm the impact of using a more standard refresh rate of, say, 60 Hz? Another non-standard thing is that you are using Magnifier, which uses Firefox's accessibility API. This appears in the performance profiles you recorded, in the Privileged Content process's markers. The accessibility notifications appear there as a RefreshObserver and the first RefreshDriverTick shows "Tick Reason: HasObservers", so, this might be what starts the cycle. Can you confirm if the issue also occurs with Magnifier closed? For this test, `about:support` should show (possibly only after a restart of Firefox): ``` Accessibility ------------- Activated: false Prevent Accessibility: 0 Accessibility Instantiator: ``` (In reply to Robbie Khan from comment #14) > I did re-launch Logitech Options+ as I do use it so yes its services would have been running although it does not seem like it in itself is the cause of any excessive CPU time from what I can gather? I guess it can be ignored if that is the case. It is correct that it seems not to have any big impact as far as I can tell (because the impact seems to correlate more with Firefox's usage of `DwmFlush`), but it can add noise that can disturb the investigation, especially because it directly interacts with DWM too. The closer we are to a standard configuration in the recordings while still reproducing the bug, the more solid our conclusions will be.