Comment 3 for bug 902594

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])