All Cappuccino applications are suffering from a very laggy behavior when resizing the browser. This happens in all Capp apps, even the smaller ones, with barely nothing. This doesn't happen in Chrome/Chromium (latest) or in Firefox It's OK that the actual Cappuccino content doesn't resize very smoothly as there is sometimes a lot of computing to do, but at least, it shouldn't make the browser's window resizing action to be so laggy. You can have an example here http://githubissues.heroku.com/
Resizing is pretty bad in both WebKit1 and WebKit2 windows, but does seem a bit worse in WebKit2. I believe this is due to weird interaction between onresize handlers and our resize model.
I've worked on this issue a little bit more, it's not just Cappuccino specific. The problem seems to be related when asking from window.screenX and screenY in the same resize event hander. For instance this dirty fragment of code will hang when resizing: <html> <script> (function(){ function onresize() { console.log(window.screenX); console.log(window.screenY); } window.addEventListener("resize", onresize); })() </script> </html> If you comment one of the two log statement, it will work smoother. I tried to add other log for innerWidth, innerHeight, screenTop, screenLeft, they don't cause any trouble. Hope this helps
<rdar://problem/10565998>
Created attachment 118820 [details] Testcase
Created attachment 118921 [details] Proposed patch
Comment on attachment 118921 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=118921&action=review > Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:110 > +#if PLATFORM(MAC) > + return m_page->windowFrameInScreenCoordinates(); > +#else Will a potentially stale value be used here as a result of this change? I'm not even sure if any WindowAndViewFramesChanged will be delivered until after the end of resizing.
(In reply to comment #6) > (From update of attachment 118921 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=118921&action=review > > > Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:110 > > +#if PLATFORM(MAC) > > + return m_page->windowFrameInScreenCoordinates(); > > +#else > > Will a potentially stale value be used here as a result of this change? I'm not even sure if any WindowAndViewFramesChanged will be delivered until after the end of resizing. What do you mean by the end of resizing? When you let go of the window edge? On my (Lion) system, there's a steady stream of WindowAndViewFramesChanged messages during resize. And this change does indeed make <http://githubissues.heroku.com/> significantly less laggy.
Comment on attachment 118921 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=118921&action=review >>> Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:110 >>> +#else >> >> Will a potentially stale value be used here as a result of this change? I'm not even sure if any WindowAndViewFramesChanged will be delivered until after the end of resizing. > > What do you mean by the end of resizing? When you let go of the window edge? On my (Lion) system, there's a steady stream of WindowAndViewFramesChanged messages during resize. And this change does indeed make <http://githubissues.heroku.com/> significantly less laggy. I think it's absolutely fine to return a stale value here - the window between resizing and the size being updated is small enough that it shouldn't matter in practice. I think Chrome does something similar.
Committed r102652: <http://trac.webkit.org/changeset/102652>
It seems that the caused bug 74418.
It seems that this also caused bug 74616.
This got reverted in <http://trac.webkit.org/changeset/103009>, reopening.
Created attachment 192119 [details] Patch II: Return from the Dead Let's fix it properly this time.
Comment on attachment 192119 [details] Patch II: Return from the Dead Is gud poch.
Committed r145169: <http://trac.webkit.org/changeset/145169>
This patch appears to have regressed http/tests/security/cross-frame-access-put.html: --- /Volumes/Data/slave/mountainlion-release-tests-wk2/build/layout-test-results/http/tests/security/cross-frame-access-put-expected.txt +++ /Volumes/Data/slave/mountainlion-release-tests-wk2/build/layout-test-results/http/tests/security/cross-frame-access-put-actual.txt @@ -520,9 +520,9 @@ ALERT: PASS: window.personalbar should be '[object BarInfo]' and is. ALERT: PASS: window.plugins should be 'undefined' and is. ALERT: PASS: window.screen should be '[object Screen]' and is. -ALERT: PASS: window.screenLeft should be '0' and is. +ALERT: PASS: window.screenLeft should be '-10000' and is. ALERT: PASS: window.screenTop matched the expected value. -ALERT: PASS: window.screenX should be '0' and is. +ALERT: PASS: window.screenX should be '-10000' and is. ALERT: PASS: window.screenY matched the expected value. ALERT: PASS: window.scrollbars should be '[object BarInfo]' and is. ALERT: PASS: window.scrollX should be '0' and is.