1. #21
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,507
    Vote Rating
    56
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    I can't see bufferResize having any real use other than to mask errors in the flow of control of rendering and sizing.

    If there are loads of doLayout calls chucked in willy-nilly to hopefully make things work, then I can see how this might improve things.

    But with Javascript being single threaded, if Jamie fixes it so that there are minimal calls to render and lay out, then I don't see what buffering either of these operations would gain.

  2. #22
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,507
    Vote Rating
    56
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


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

    When dragging a splitter with the mouse, or resizing a Window, then the resize event definitely needs to be buffered. We do not want a cascade of laying out triggered for every pixel moved.

  3. #23
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    The patch set ties some things together:

    1. There were 2 lines pulled from Ext JS 2.3.0 (unfortunately, the 2 lines will not work with the layout 2.0 logic as it complements the buffering logic).

    2. I restored just enough lines from Ext JS 3.0.3 to get buffering working again. This is actually very valuable. Look at the decrease in the number of calls with this.

    3. I pulled 2 lines from the layout 2.0 logic. The 2 lines complement the change applied to SVN 5691.

    I nearly gave up on this research. However, it all came together this past Sunday as if by accident. It's quite a small patch and fully tested.

  4. #24
    Sencha Premium Member
    Join Date
    Oct 2009
    Location
    Germany
    Posts
    330
    Vote Rating
    1
    PranKe01 is on a distinguished road

      0  

    Default


    I don't see any faster rendering when rezising in my Air app I only have to change the code in the ext-all-debug.js, right?

  5. #25
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    Quote Originally Posted by Animal View Post
    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).

  6. #26
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    Quote Originally Posted by PranKe01 View Post
    I don't see any faster rendering when rezising in my Air app I only have to change the code in the ext-all-debug.js, right?
    Read this: http://www.extjs.com/forum/showthrea...281#post424281

    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.

  7. #27
    Sencha Premium Member
    Join Date
    Oct 2009
    Location
    Germany
    Posts
    330
    Vote Rating
    1
    PranKe01 is on a distinguished road

      0  

    Default


    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.

  8. #28
    Sencha User
    Join Date
    Jun 2009
    Posts
    750
    Vote Rating
    0
    meroy is on a distinguished road

      0  

    Default


    Quote Originally Posted by PranKe01 View Post
    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.

    Code:
        <!-- ** Javascript ** -->
        <!-- ExtJS library: base/adapter -->
        <script type="text/javascript" src="../../adapter/ext/ext-base.js"></script>
    
        <!-- ExtJS library: all widgets -->
        <script type="text/javascript" src="../../ext-all.js"></script>
    
        <!-- overrides to base library -->
    
        <script type="text/javascript">
           Ext.Container.prototype.bufferResize = false;
        </script>

  9. #29
    Sencha User Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661
    Vote Rating
    20
    Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough

      0  

    Default


    Quote Originally Posted by Animal View Post
    I can't see bufferResize having any real use other than to mask errors in the flow of control of rendering and sizing.

    If there are loads of doLayout calls chucked in willy-nilly to hopefully make things work, then I can see how this might improve things.

    But with Javascript being single threaded, if Jamie fixes it so that there are minimal calls to render and lay out, then I don't see what buffering either of these operations would gain.
    Very true, things have gotten a bit hectic and for 3.1.1 I'm cleaning out all these extra calls and the crutch of bufferResize should go away.

  10. #30
    Sencha User Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661
    Vote Rating
    20
    Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough Jamie Avins is a jewel in the rough

      0  

    Default


    Quote Originally Posted by Animal View Post
    Actually, there is a good case for buffering resize actions. Not for the initial render performance though.

    When dragging a splitter with the mouse, or resizing a Window, then the resize event definitely needs to be buffered. We do not want a cascade of laying out triggered for every pixel moved.
    The onWindowsResize needs some cleaning but that is a different buffered event.