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

      0  

    Default


    That sounds very exciting.

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

      0  

    Default


    Just want to chime in here and say that I'm anxious to get off work today and go home to write my findings including the patch. This patch takes a different path and improves the rendering speed and addresses the resizing issue.

    For example, using Safari under Windows, folks can choose on whether to set bufferResize to true or false or just use the default setting. Setting to false imitates the layout 2.0 code as bufferResize is set to false there. Using the portal/portal.html demo, I'm seeing the desktop background momentarily inside the window along the edge as I resize the window back and forth. With bufferResize using the default in Ext JS or setting it to true has a much nicer look. I can never get the desktop background to show through no matter how fast I resize the window. It's very nice.

    I believe that the more complex the app becomes, the more value bufferResize provides. There are comments here in Ext JS's source that bufferResize will be deprecated. This is what prompted me to get busy -- very busy

    By the way, I'm totally cool and okay if the dev team decides to remove bufferResize altogether. However, at the very least, I at least tried to save it. Who knows, the new layout 2.0 code that Jamie is working on may prove to be extremely fast. That will eventually not be able to keep up as apps become increasingly more complex. Well, that's what I believe in my humble opinion when simulating this.

    This was all fun and I think the dev team will enjoy it including Animal when I post later on this evening.

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

      0  

    Default


    The first test results are in.

    Below shows the number of calls when maximizing and restoring the browser window. The test was done using Firefox 3.5.6 under Windows XP. The screen resolution for the external monitor was set to 1440 by 900 pixels.

    The example used was layout-browser/layout-browser.html. Before clicking on Profile, go to: Combination Examples --> Tabs with Nested Layouts --> Inner Tab 2 --> Nested Grid. Press Profile, then the F11 key and Profile again after resizing completes.

    Please note that Nige's new Layout 2.0 code has been turned over to Jamie. I'm sure that this one will improve over the scores shown below. The New Patch takes a different path and restores the buffering logic (part of it) from 3.0.3 and a couple lines from Ext JS 2.3.0. It also takes a couple lines from Nige's patch which were missed somehow to go with the change made in SVN 5691.

    In any event, enjoy the results.

    Code:
     
    Maximize Window Test / Number of calls
     
                     (bufferResize value)
    Ext JS Release    false    true     150
    ===============  ======  ======  ======
    3.0.3.........:  19,841  17,476  12,310
    SVN 5847......:  11,029  11,026  11,028
    Layout Nige...:   7,864   7,866   7,864
    New Patch.....:   7,870   8,286   6,688   <-- look at this number, absolutely amazing
     
    Look how close the New Patch performs to Nige's patch
    when bufferResize is set to false. It reaches it
    without affecting the rendering speed (next post).
     
    Buffering logic does take the lead when set to 150.
    Please reconsider before removing the buffering logic.
    The more complex the app, the more value it provides.
     
    Above, we see that only 3.0.3 and the New Patch
    improves performance with buffering enabled.
     
     
    Restore Window Size / Number of calls
     
                     (bufferResize value)
    Ext JS Release    false    true     150
    ===============  ======  ======  ======
    3.0.3.........:   6,892   5,583   5,583
    SVN 5847......:   3,825   3,824   3,824
    Layout Nige...:   2,770   2,770   2,770
    New Patch.....:   2,772   2,910   2,884
     
    The performance is still good when bufferResize is
    set to 150.  The combined effort maximize/restore
    of the New Patch still takes the lead.
     
    It performs as well as the Layout 2.0 logic when
    bufferResize is set to false.

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

      0  

    Default


    Hi,
    I apllied the patch from here: http://www.extjs.com/forum/showthread.php?t=88546
    I am running Ext3.1 but did not noticed a faster rendering when resizing the Adobe Air window I used the ext-all-debug.js and modified it by hand.
    Are there other patches, or am I doing something wrong?

    P.S. Will this patch be included in ext 3.1.1?

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

      0  

    Default


    To help make the layout 2 logic render faster and more of a level playing field, I reverted the canLayout logic to that of what's in trunk. Also, to address an issue with one layout, I moved one line (was called too early) in doLayout. The numbers above for the layout 2.0 logic was done against this modified version.

    In any event, the new patch has achieved several things.

    1. It renders as fast if not faster than the current trunk, closer to 3.0.3.
    2. It keeps up with the layout 2 logic for initial rendering when bufferResize is set to false.
    3. The flexibility in allowing developers to set bufferResize to better suite the complexity of the application.

    Tonight, I've seen the resizing of an app having 150 tabs spread across 2 card panels. Amazingly, the new patch with bufferResize set to false looks and feels very much like the layout 2.0 logic. Enabling buffering gives it a nice touch though.

    Firefox has an issue with performing an object lookup inside the getStyle function. The object var in that function is cs: cs[prop]. This can only be addressed by the Firefox developers. There's nothing that can be done by Ext JS to minimize this.

  6. #16
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,483
    Vote Rating
    35
    Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    It's not just doing an object lookup. What looks like a property access is in fact calling a getter which calculates that style attribute's value by interrogating applicable CSS rules.

  7. #17
    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
    Hi,
    I apllied the patch from here: http://www.extjs.com/forum/showthread.php?t=88546
    I am running Ext3.1 but did not noticed a faster rendering when resizing the Adobe Air window.
    I haven't posted my completed patch yet and will do so within the next hour in this thread. That patch at that URL is only half of it. I believe that Nige's patch (Layout 2.0) is what folks will see in the 3.2 release. The patch I'm providing here was done personally for me and will share. It's solid and very small.

  8. #18
    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
    It's not just doing an object lookup. What looks like a property access is in fact calling a getter which calculates that style attribute's value by interrogating applicable CSS rules.
    Thanks for the clarification on this.

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

      0  

    Default


    The performance increase for resizing comes mainly from these 2 files.

    Code:
    diff -r -U 4 svn.ext-5847/src/widgets/Container.js svn.ext-5847-b2/src/widgets/Container.js
    --- svn.ext-5847/src/widgets/Container.js   2009-12-22 03:42:34.000000000 -0500
    +++ svn.ext-5847-b2/src/widgets/Container.js    2010-01-03 20:22:23.000000000 -0500
    @@ -487,17 +487,18 @@
             if(Ext.isDefined(this.activeItem)){
                 var item = this.activeItem;
                 delete this.activeItem;
                 this.layout.setActiveItem(item);
    +            return;
             }
    
             // If we have no ownerCt and the BoxComponent's sizing did not trigger a layout, force a layout
             if(!this.ownerCt && !this.layoutDone){
                 this.doLayout(false, true);
             }
    
             if(this.monitorResize === true){
    -            Ext.EventManager.onWindowResize(this.doLayout, this, [false]);
    +            Ext.EventManager.onWindowResize(this.layout.layout, this.layout);
             }
         },
    
         /**
    @@ -841,8 +842,24 @@
             }
         },
    
         // private
    +    shouldBufferLayout: function(){
    +        /*
    +         * Returns true if the container should buffer a layout.
    +         * This is true only if the container has previously been laid out
    +         * and has a parent container that is pending a layout.
    +         */
    +        var hl = this.hasLayout;
    +        if(this.ownerCt){
    +            // Only ever buffer if we've laid out the first time and we have one pending.
    +            return hl ? !this.hasLayoutPending() : false;
    +        }
    +        // Never buffer initial layout
    +        return hl;
    +    },
    +
    +    // private
         hasLayoutPending: function(){
             // Traverse hierarchy to see if any parent container has a pending layout.
             var pending = this.layoutPending;
             this.ownerCt.bubble(function(c){
    @@ -880,9 +897,9 @@
                     this.doRemove(c, true);
                 }
             }
             if(this.monitorResize){
    -            Ext.EventManager.removeResizeListener(this.doLayout, this);
    +            Ext.EventManager.removeResizeListener(this.layout.layout, this.layout);
             }
             Ext.destroy(this.layout);
             Ext.Container.superclass.beforeDestroy.call(this);
         },
    diff -r -U 4 svn.ext-5847/src/widgets/layout/ContainerLayout.js svn.ext-5847-b2/src/widgets/layout/ContainerLayout.js
    --- svn.ext-5847/src/widgets/layout/ContainerLayout.js  2009-12-22 03:42:34.000000000 -0500
    +++ svn.ext-5847-b2/src/widgets/layout/ContainerLayout.js   2010-01-03 20:22:54.000000000 -0500
    @@ -151,25 +151,20 @@
    
             if (ct.collapsed){
                 return;
             }
    -
    -        // Not having an ownerCt negates the buffering: floating and top level
    -        // Containers (Viewport, Window, ToolTip, Menu) need to lay out ASAP.
    -        if (b && ct.ownerCt) {
    -            // If we do NOT already have a layout pending from an ancestor, schedule one.
    -            // If there is a layout pending, we do nothing here.
    -            // buffering to be deprecated soon
    -            if (!ct.hasLayoutPending()){
    +        if(b = ct.bufferResize){
    +            // Only allow if we should buffer the layout
    +            if(ct.shouldBufferLayout()){
                     if(!this.resizeTask){
                         this.resizeTask = new Ext.util.DelayedTask(this.runLayout, this);
                         this.resizeBuffer = Ext.isNumber(b) ? b : 50;
                     }
                     ct.layoutPending = true;
                     this.resizeTask.delay(this.resizeBuffer);
                 }
             }else{
    -            ct.doLayout(false, this.forceLayout);
    +            ct.layout.layout();
             }
         },
    
         // private
    The following is optional and not required. It does cut down the number of calls though when buffering is enabled. But not by much. The results above included this. This too was fully tested.

    Code:
    diff -r -U 4 svn.ext-5847/src/widgets/Panel.js svn.ext-5847-b2/src/widgets/Panel.js
    --- svn.ext-5847/src/widgets/Panel.js   2009-12-21 18:45:44.000000000 -0500
    +++ svn.ext-5847-b2/src/widgets/Panel.js    2010-01-03 09:01:43.000000000 -0500
    @@ -848,9 +848,9 @@
                 };
             }
             result = tb.events ? Ext.apply(tb, options) : this.createComponent(Ext.apply({}, tb, options), 'toolbar');
             result.ownerCt = this;
    -        result.bufferResize = false;
    +     // result.bufferResize = false;
             this.toolbars.push(result);
             return result;
         },
    
    diff -r -U 4 svn.ext-5847/src/widgets/menu/Menu.js svn.ext-5847-b2/src/widgets/menu/Menu.js
    --- svn.ext-5847/src/widgets/menu/Menu.js   2009-12-09 14:24:15.000000000 -0500
    +++ svn.ext-5847-b2/src/widgets/menu/Menu.js    2010-01-03 09:00:55.000000000 -0500
    @@ -199,9 +199,9 @@
         hideMode : 'offsets',    // Important for laying out Components
         scrollerHeight : 8,
         autoLayout : true,       // Provided for backwards compat
         defaultType : 'menuitem',
    -    bufferResize : false,
    + // bufferResize : false,
    
         initComponent : function(){
             if(Ext.isArray(this.initialConfig)){
                 Ext.apply(this, {items:this.initialConfig});
    The following will address auto width/height issues.

    Code:
    diff -r -U 4 svn.ext-5847/src/widgets/layout/BoxLayout.js svn.ext-5847-b2/src/widgets/layout/BoxLayout.js
    --- svn.ext-5847/src/widgets/layout/BoxLayout.js    2009-12-22 03:42:34.000000000 -0500
    +++ svn.ext-5847-b2/src/widgets/layout/BoxLayout.js 2010-01-03 08:55:33.000000000 -0500
    @@ -227,8 +227,14 @@
             for (i = 0 ; i < csLen; i++) {
                 c = cs[i];
                 cm = c.margins;
                 totalFlex += c.flex || 0;
    +
    +            // autoHeight Containers must be fully laid out to acquire a height
    +            if (c.doLayout && !c.height && !c.hasLayout) {
    +                c.doLayout();
    +            }
    +
                 ch = c.getHeight();
                 margin = cm.top + cm.bottom;
                 extraHeight += ch + margin;
                 flexHeight += margin + (c.flex ? 0 : ch);
    @@ -346,8 +352,14 @@
    
             Ext.each(cs, function(c){
                 cm = c.margins;
                 totalFlex += c.flex || 0;
    +
    +            // autoWidth Containers must be fully laid out to acquire a width
    +            if (c.doLayout && !c.width && !c.hasLayout) {
    +                c.doLayout();
    +            }
    +
                 cw = c.getWidth();
                 margin = cm.left + cm.right;
                 extraWidth += cw + margin;
                 flexWidth += margin + (c.flex ? 0 : cw);
    The following will address tab panel issues. The beforeDestroy function in Form.js is taken from 3.0.3. So, you can look there if needed.

    Code:
    diff -r -U 4 svn.ext-5847/src/widgets/layout/CardLayout.js svn.ext-5847-b2/src/widgets/layout/CardLayout.js
    --- svn.ext-5847/src/widgets/layout/CardLayout.js   2009-12-10 22:23:57.000000000 -0500
    +++ svn.ext-5847-b2/src/widgets/layout/CardLayout.js    2010-01-03 08:56:10.000000000 -0500
    @@ -86,9 +86,9 @@
         renderHidden : true,
    
         constructor: function(config){
             Ext.layout.CardLayout.superclass.constructor.call(this, config);
    -      //  this.forceLayout = (this.deferredRender === false);
    +        this.forceLayout = (this.deferredRender === false);
         },
    
         /**
          * Sets the active (visible) item in the layout.
    diff -r -U 4 svn.ext-5847/src/widgets/form/Form.js svn.ext-5847-b2/src/widgets/form/Form.js
    --- svn.ext-5847/src/widgets/form/Form.js   2009-11-09 15:37:29.000000000 -0500
    +++ svn.ext-5847-b2/src/widgets/form/Form.js    2010-01-03 08:59:16.000000000 -0500
    @@ -194,15 +194,16 @@
    
         // private
         beforeDestroy : function(){
             this.stopMonitoring();
    +        Ext.FormPanel.superclass.beforeDestroy.call(this);
             /*
    +         * Clear the items here to prevent them being destroyed again.
              * Don't move this behaviour to BasicForm because it can be used
              * on it's own.
              */
    -        Ext.destroy(this.form);
             this.form.items.clear();
    -        Ext.FormPanel.superclass.beforeDestroy.call(this);
    +        Ext.destroy(this.form);
         },
    
         // Determine if a Component is usable as a form Field.
         isField : function(c) {

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

      0  

    Default


    You can adjust this in your app. Include the following after ext-all.js or ext-all-debug.js.

    Code:
     <script type="text/javascript">
        Ext.Container.prototype.bufferResize = true;
     </script>
    Try false, true or set it to 150 if you have a large app. If 150 is too much, try 100. For Air apps, true or false are sufficient. You will like how Air/Safari/Chrome resizes if you set this to true which is the default. Remember to try false too to get a feel of that one. The flexibility is there. Even bufferResize could be set dynamically depending on what users are using for browser with if statements with things like isIE, etc.

    The numeric results (number of calls) were obtain with this patch set. The patch is actually quite small and fully tested including setting bufferResize to true/false and even 150.

    In any event, enjoy the findings posted here.

    Mario

film izle

hd film izle

film sitesi

takipci kazanma sitesi

takipci kazanma sitesi

güzel olan herşey

takipci alma sitesi

komik eğlenceli videolar