Actually, there is a good case for buffering resize actions. Not for the initial render performance though.

Yes and thank you. Buffering does have value for resizing. Look at the decrease in number of calls up thread when I compared this.

All I'm asking is for folks to reconsider buffering before removing it entirely from the source. There's a comment in there that this will be deprecated. Somebody put it there for a reason and it must of been a valid one at the time.

If anything, copy svn.ext-5847 as svn.ext-5847-b2 and apply the patch. Then, check out portal/portal.html with Safari. Resize the window as fast as you can. Now set bufferResize to false and do the same. Notice how it appears like the layout 2.0 logic. Look how close up thread "number of calls" when comparing to the layout 2.0 logic (bufferResize set to false).

Set bufferResize and try false. I don't know the complexity of your app. Try true which is the default. Try resizing your window. Does the edge of your window follow your mouse.

The layout is buffered by default or set to true. Therefore, there's the small lapse before things get rendered. Perhaps, you want to set bufferResize to false if you're wanting things to layout immediately while resizing.

A better approach would be to apply this to the actual source files and use JSBuilder2 to build. Then, you would get ext-all.js and ext-all-debug.js with this patch. Perhaps, an override containing this may be helpful.

I set the variable to true, false and also to 150. The edge of ma app is following my mouse, but the items in the app (like grids, which are resizing or tabs) does not.

Have you applied the entire patch (the first 2 files) -- first code block. You want to set this to false. Do this after including ext-all-debug.js.

Ext.Container.prototype.bufferResize = false;

Check to ensure you're not setting this elsewhere.

Try the portal/portal.js example. Have that use your patched ext-all-debug.js file. Set bufferResize to false. With Safari, under Leopard, the components resize nearly as fast when resizing the window. However, the edge of the window isn't always able to follow the mouse. Buffering helps allow the edge of the window to follow the mouse immediately. The effect is different with buffering. Components resize and snap into place after resizing. It looks like you're wanting things to resize immediately in which case false is the setting you need. I'm not sure how Air operates although it uses the WebKit engine. Maybe it is caching resize operations behind the scene.

Also try the layout-browser/layout-browser.html demo. Pull up the tab having the grid. Do the same there. I just tested this and it works. For me personally, I prefer Safari to follow my mouse immediately and to snap into place the resizing of the componets "effect" inside the window once I release the mouse.

In the portal.html file, I have this if you want to disable buffering.