This issue is completely reproducible in midori 3.4 using webkitgtk 1.6.3 and gtk 3.2.3.
Test regimen:
Test 1:
- Run midori with one open blank window/tab.
- CPU should baseline at 0%
- Load a static page: /usr/share/doc/midori/faq.html
- Observe CPU. Should still be at 0%
(conclusion: issue is unrelated to static web content)
Test 2:
- Run midori
- Load a web page from the internet that is either static or has no repeating javascript events
- Observe CPU. Should still be at 0%
(conclusion: issue is not directly related to any page content from network sources)
Test 3:
- Run midori using an empty page (set your default to an empty page or empty speeddial)
- CPU should be at 0%
- Open another empty page
- CPU should be at 0%
- Open another empty page
- CPU should be at 0%
- Minimize midori
- CPU should be at 0%
- Un-minimize midori
- CPU should be at 0%
- Select the first tab
- CPU usage climbs to around 30 - 40% (depending on your CPU)
- Select the second tab
- CPU stays high
- Minimize
- CPU stays high
- Un-minimize
- CPU stays high
- Close the 2nd tab
- CPU stays high
(conclusion: midori code that controls the tab selection or view repaint code is not deregistering the new tab view from repaint or update event. unrelated to any underlying X redraw or backing store refresh)
Test 4:
- open midori with an empty page
- open a new empty tab
- close the new empty tab
- CPU climbs to 30-40%
(conclusion: since the close event forces an implicit "change view" then it doesn't have anything to do with the user actually selecting the tab. It's very likely that a change or bug in the gtk3 API for registering redraw events causes this. It's also possible that gtk3 API finally properly implements its redraw registration API which exposes a bug in midori or possibly webkitgtk [although that would be unlikely since epiphany/gtk3 doesn't exhibit this behavior])
This issue is completely reproducible in midori 3.4 using webkitgtk 1.6.3 and gtk 3.2.3.
Test regimen:
Test 1:
- Run midori with one open blank window/tab. doc/midori/ faq.html
- CPU should baseline at 0%
- Load a static page: /usr/share/
- Observe CPU. Should still be at 0%
(conclusion: issue is unrelated to static web content)
Test 2:
- Run midori
- Load a web page from the internet that is either static or has no repeating javascript events
- Observe CPU. Should still be at 0%
(conclusion: issue is not directly related to any page content from network sources)
Test 3:
- Run midori using an empty page (set your default to an empty page or empty speeddial)
- CPU should be at 0%
- Open another empty page
- CPU should be at 0%
- Open another empty page
- CPU should be at 0%
- Minimize midori
- CPU should be at 0%
- Un-minimize midori
- CPU should be at 0%
- Select the first tab
- CPU usage climbs to around 30 - 40% (depending on your CPU)
- Select the second tab
- CPU stays high
- Minimize
- CPU stays high
- Un-minimize
- CPU stays high
- Close the 2nd tab
- CPU stays high
(conclusion: midori code that controls the tab selection or view repaint code is not deregistering the new tab view from repaint or update event. unrelated to any underlying X redraw or backing store refresh)
Test 4:
- open midori with an empty page
- open a new empty tab
- close the new empty tab
- CPU climbs to 30-40%
(conclusion: since the close event forces an implicit "change view" then it doesn't have anything to do with the user actually selecting the tab. It's very likely that a change or bug in the gtk3 API for registering redraw events causes this. It's also possible that gtk3 API finally properly implements its redraw registration API which exposes a bug in midori or possibly webkitgtk [although that would be unlikely since epiphany/gtk3 doesn't exhibit this behavior])