Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-3364 in 3.0.7.
  1. #1
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    57
    Vote Rating
    0
    walkerr is on a distinguished road

      0  

    Default Suggestions on cause of panel/table resize lag?

    Suggestions on cause of panel/table resize lag?


    Anyone else experience a significant lag/slowness on resizing panels or tables when the outer browser window is resized?

    Resize seems to happen fine, including addition of scrollbars when teh size warrants it, but it seems to take forever. It is markedly worse on IE than FF. IE can take several seconds before it sorts the sizing out. FF has a visible lag, but it's more of a "choppiness" in the sizing whereas IE just sits there with the old size for seconds while it gets the size right.

    The panel in question is a Grid inside a VerticalLayoutContainer, using UiBinder for panel layout:

    Code:
        <row:VerticalLayoutContainer borders="true" height="1" width="1">
    	     <row:child>
    	       <toolbar:ToolBar>
                    <button:ToolButton ui:field="btnRefresh" config='{refreshCfg}' toolTip="Refresh the list of sessions."/>
                    <button:ToolButton ui:field="btnDisconnect" config='{discCfg}' enabled='false' toolTip="Disconnect the selected sessions."/>
    	        </toolbar:ToolBar>
    	     </row:child>
    	     <!--  layout data here ensures teh grid view has a size which then also triggers scroll bars when needed -->
    	     <row:child layoutData="{middleData}">
    	        <grid:Grid ui:field="grid" store="{store}" cm="{cm}" view="{view}" columnReordering="true" borders="false">
    		   </grid:Grid>
    	    </row:child>
        </row:VerticalLayoutContainer>
    This in turn sits inside our overall viewport and an outer GWT panel that houses our main panel. We pass the resize event down as an explicit call to any child panel occupying the main panel space as follows:

    Code:
                else if (this.currViewWidget instanceof com.sencha.gxt.widget.core.client.Component)
                {
                    com.sencha.gxt.widget.core.client.Component comp = (com.sencha.gxt.widget.core.client.Component) this.currViewWidget;
                    comp.setWidth(width);
                    comp.setHeight(height);
                }
    We have a legacy mix of old panels based on GWT-Ext, hence the conditional code as we need to deal with other types of panel component in this area of our UI.

  2. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    First, a note on your last remark - the instanceof should be nice and cheap, so I wouldn't worry about that, it certainly wouldn't introduce a lag like what you are talking about.

    Can you share a little more context on what is going on here, widget-structure wise? I see that the VLC contains a grid and uses a 'middleData' object for its layout, but what is that layout? Why does the VLC get its size set to 1px by 1px? What is the VLC's parent, and *its* parent, all the way up to the root of the page (either RootPanel or RootLayoutPanel)?

    Have you done any performance measuring, perhaps with firebug or DynaTrace?

  3. #3
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    57
    Vote Rating
    0
    walkerr is on a distinguished road

      0  

    Default


    Quote Originally Posted by Colin Alworth View Post
    Can you share a little more context on what is going on here, widget-structure wise? I see that the VLC contains a grid and uses a 'middleData' object for its layout, but what is that layout? Why does the VLC get its size set to 1px by 1px? What is the VLC's parent, and *its* parent, all the way up to the root of the page (either RootPanel or RootLayoutPanel)?
    To be honest, it's all a bit guesswork for me at the moment - I don't have a full grasp on how the various components interact, and I don't find the documentation very clear or comprehensive on how the various layout elements work together

    The two problems I was battling was getting the Grid to resize at all when the outer container size changed, and secondly getting scrollbars to appear correctly i.e. on the Grid, as opposed to not appearing at all, or appearing on the VLC which causes the column headings to also get scrolled.

    I eventually found a pointer to the following example after a lot of searching on your forums:

    http://www.sencha.com/examples/#Exam...nguibindergrid

    I'm not sure what the "1" sizing does - I copied it from the above, and it made the difference. I think I read it forces a 100% fill of the outer panel (in fact I think it was one of your responses to a different layout problem which suggested that).

    The GXT VLX itself sits inside a simple Panel, which is itself the center element of a BorderLayout, and above that is the RootPanel only.

    Quote Originally Posted by Colin Alworth View Post
    Have you done any performance measuring, perhaps with firebug or DynaTrace?
    Have asked a colleague who is more experienced with the above tools to see if he can get any insight

  4. #4
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Its a little late now for me to do too much of a reply, so I'm going to give you some links and a few quick remarks, then follow up with whatever else you have in the morning.

    First, links - check our our docs. These are going to see a refresh when we push out 3.1, but for now they seem to be doing the job fairly well. A few layout-specific ones:
    Concepts > Layouts - Why a layout system exists, application vs document layouts, and a bit of how to think in layouts
    UI > Layout > Layout Containers - a quick look at most of the containers in GXT
    UI > Layout > Vertical Layout Container - a little more detail on the VLC, how to size with it (including what does that 1.0 value mean).

    The basic premise of layouts it that you have the full space in the user's browser, and need to subdivide the space to avoid page (i.e. document) scrollbars. Making sure to use layouts that size their *children* rather than being sized to them is key to this.

    Start with a Viewport, attached to the RootPanel, so that you have all of the available browser space, and size on down from there. The fact that you didn't mention a Viewport makes me concerned as to what exactly is doing the sizing in your app as the user resizes - something custom?

    Each step of the way, make sure that you are picking up the tool for the job, and never doing something like adding a ContentPanel with header and border hidden, since that just adding wrapper without any extra utility. You mentioned a Panel - did you mean ContentPanel, or are you using GWT's Panel class, which doesn't have any resizing capabilities? Note that some GWT classes do understand application layouts, but these are all *LayoutPanel, which implement ProvidesResize and/or RequiresResize.

    When looking at performance, make sure you are measuring compiled code, never dev mode. Dev mode has completely different performance and memory characteristics than what you'll see from production. To use browser profiling tools, compile with style set to PRETTY or DETAILED (either is readable, DETAILED is downright verbose) and measure that.

    Consider filing a support ticket to have us help you out, either by taking a look at code, or performance data, or even walking through analyzing your apps performance.

    Pages should be fairly responsive with GXT 3 - browsers and computers are still getting faster (unless you are stuck back in IE8-land I guess), and GXT 3 is almost twice as fast as GXT 2 in some areas, and never slower. That said, bugs happen too, so make sure that stripped down examples are as fast as expected, as well as our explorer demo.

  5. #5
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    57
    Vote Rating
    0
    walkerr is on a distinguished road

      0  

    Default


    Thanks, will read through the Doc references.

    Sorry, forgot to mention the Viewport, yes we do use one.

    The exact hierarchy is as follows:

    Code:
    RootPanel
    |-> com.gwtext.client.widgets.Viewport
          |-> com.gwtext.client.widgets.Panel (with BorderLayout)
                |-> com.gwtext.client.widgets.Panel (in Center element of BorderLayout)
                      |-> The UiBinder component containing the VLC with the Grid inside it
    The reason for GWT-Ext components here is our legacy code, which is still the bulk of our panels. So far, in all examples I've tried, this has caused side effects. Will try and create an isolated example on this one with just GWT and GXT components.

    Note that is is only the Grid/Grid View that is slow to resize - the outer VLC resizes almost instantly, and then a few seconds later the Grid catches up and resizes within it. This made me wonder at column resize calculations being a possible cause, and also suggested that it wasn't really related to the outer containers at all, since their resize seems almost instant all teh way down to, and including the VLC.

    Each step of the way, make sure that you are picking up the tool for the job, and never doing something like adding a ContentPanel with header and border hidden, since that just adding wrapper without any extra utility
    We're actually not using a ContentPanel at all when we get to this panel - just a VLC to give us the top toolbar, and the Grid within it. If GridView allowed a top toolbar, I guess we could ditch the VLC too - but doesn't seem too.

    When looking at performance, make sure you are measuring compiled code, never dev mode. Dev mode has completely different performance and memory characteristics than what you'll see from production.
    Yep - behaviour is the same in fact whether in Hosted mode or fully compiled. IE lags, FF is "notchy" on resize but quicker.

    Consider filing a support ticket to have us help you out, either by taking a look at code, or performance data, or even walking through analyzing your apps performance.
    Can you advise how this works with us still being in a product evaluation customer? Specifically, does it use up our x-Credits, and do these get credited back if it turns out our efforts/usage has helped Sencha find a bug?

    (unless you are stuck back in IE8-land I guess)
    Interesting that you mention that - our products are used by large enterprises, and some of these even still have IE6 and 7, although thankfully we are seeing this diminish. I forget exactly where we've had to make tweaks to support these guys (PNG transparency was one I recall, although I think we scrapped that mod now). We do include the following in our base HTML from which the GWT app is loaded:

    Code:
    <!DOCTYPE html>
    <html>
    <head>
        <meta http-equiv="X-UA-Compatible" content="IE=6, IE=7, IE=8" >
    From memory, there were some quite basic GWT panels or components that threw exceptions if we didn't have this in.

  6. #6
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Starting at the bottom, working my way up:
    Code:
    <!DOCTYPE html>
    <html>
    <head>
        <meta http-equiv="X-UA-Compatible" content="IE=6, IE=7, IE=8" >
    From memory, there were some quite basic GWT panels or components that threw exceptions if we didn't have this in.
    This is probably due to the fact that gwtext hasn't been updated in quite a long time, and may simply not support newer browsers. This statement puts IE9+ into compatibility mode, where it poorly emulates older browsers. For this reason, we don't support this mode, since it can cause all kinds of issues that dont show up in the real browser, either IE9 behaving like itself, or IE6 or 7.

    Interesting that you mention that - our products are used by large enterprises, and some of these even still have IE6 and 7, although thankfully we are seeing this diminish.
    GWT 2.6, which is due to be released in the next few weeks is removing IE6/7 support, and GXT 3.1 will in turn drop support as well in order to take advantage of this new version.

    Can you advise how this works with us still being in a product evaluation customer? Specifically, does it use up our x-Credits, and do these get credited back if it turns out our efforts/usage has helped Sencha find a bug?
    A bug filed by a support customer, whether on the forums or in a support ticket is given a higher than normal priority, but neither costs any x-credits - if an reported by a support ticket is accepted as a bug, the x-credits will be refunded.

    Yep - behaviour is the same in fact whether in Hosted mode or fully compiled. IE lags, FF is "notchy" on resize but quicker.
    Do not measure (or measure, but just ignore) any hosted mode times - JSNI calls take tremendously longer, and math, collections operations are faster than they should be.

    Yep - behaviour is the same in fact whether in Hosted mode or fully compiled. IE lags, FF is "notchy" on resize but quicker.
    IE lags, fact of life. FF's behavior might be FF, since at least on windows, there are (at least?) two sets of handles to resize the browser, and only one of those (bottom right corner, with the dots) actually passes size info right away to the page so that it can be processed. Using the side handles often results in much choppier resizing, since the browser doesn't notify as frequently for whatever reason - this doesn't seem to happen in OS X however...

    Note that is is only the Grid/Grid View that is slow to resize - the outer VLC resizes almost instantly, and then a few seconds later the Grid catches up and resizes within it. This made me wonder at column resize calculations being a possible cause, and also suggested that it wasn't really related to the outer containers at all, since their resize seems almost instant all teh way down to, and including the VLC.
    That's interesting, thanks for the clarification. The Grid has some code in it to protect the rest of the page from any performance issues by deferring its work, but I'm not at present seeing any of that work done around a resize, just when data is added, or the grid initially put on the page. This certainly sounds like it might be of interest, but I'll need a little more data (use case, timing info, etc) around here to say anything for sure.

    The reason for GWT-Ext components here is our legacy code, which is still the bulk of our panels. So far, in all examples I've tried, this has caused side effects. Will try and create an isolated example on this one with just GWT and GXT components.
    This is my biggest concern - GWT-Ext is based on Ext JS 2.2 or so, which was old before GXT 2 was released. The last changes (according to a quick glance at http://code.google.com/p/gwt-ext/source/browse/) were in 2008, whereas IE8 was released several months into 2009. I don't know how well GWT-Ext plays nicely with other GWT widgets, especially GWT LayoutPanels or GXT layout containers, but my first test would be to look very closely at how it is passing along sizing data into GXT, to see if perhaps this could be improved.

  7. #7
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    57
    Vote Rating
    0
    walkerr is on a distinguished road

      0  

    Default


    Thanks for the reply Colin, and the explanation of the x-credit/support process.

    At this stage it's very hard for me to tell whether it's some ripple down effect from the outer GWT-Ext containers, or something actually in GXT. I can say it's not a dev/hosted mode side effect - same behaviour fully compiled or in hosted mode.

    I'll try and isolate the Grid into a standalone example before reposting here or submitting a ticket. Without that, there's just too many variables to figure the root cause. My gut feel says it is something in Grid resize handling only on IE, but it could well be a knock-on from the legacy widgets in the hiearchy above this panel. We do have plans to refactor the outer framework with up-to-date GXT and GXT containers, and at the same time remove the browser compatibility kludge from our HTML, but that work isn't due to start just yet.

    I'll be on the road now for 10 days - may get time to experiment more though. Will post back if/when I have an isolated example.

  8. #8
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    57
    Vote Rating
    0
    walkerr is on a distinguished road

      0  

    Default Isolated example

    Isolated example


    Turned out to be quite easy to create an isolated example (ZIP attached below). Hacked into the outline from one of your showcase examples, servlet.jar removed to save space.

    This one in fact seems laggy in both FF and IE on my machine. Try a horizontal resize - shrinking or expanding window. If you do the resize slowly hold the mouse button down, you get a sort of "notchy resize" where the grid catches up. Do a very fast resize though and it sits for 20 or 30 seconds worst case on my machine until the grid catches up.

    Note that the VLC toolbar seems to resize immediately - it's only the grid which seems to stall on resize.

    Something I noticed in attempting to capture screenshots is that whether the mouse is over the browser window or not seems to affect the resize. What seems to happen is that if you do a very quick resize - and leave the mouse outside the IE or FF window afterwards, the table columns do not resize. Move the mouse back over the browser window, and the grid snaps into place. So it seems to be that if the mouse is outside the browser window after the resize, it halts the resize calculation.

    I've tried to screen shot these below - shots were done in hosted mode, as this was easier for the isolate example, but we see the same behaviour in our full app example in compiled mode, so I don't think this is a factor

    Mouse outside after resize (smaller):

    shrink-stall.jpg

    Mouse outside after resize (wider):

    expand-stall.jpg

    Moment the mouse moves back over the browser in the above 2 cases it snaps back to correct size.

    resize-over.jpg

    In both cases, if you leave it long enough, it will eventually resize without the mouse moving over the browser window. We're talking 30 seconds plus in some cases though.
    Attached Files

  9. #9
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,731
    Vote Rating
    90
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Great test sample - a little verbose here and there, but nothing that got in the way of finding the issue.

    I'm on my way to a GWT meetup (to be broadcast online at https://plus.google.com/events/cvle2...kdn2h158os850c), so, the short version now, to be followed up a much more in-depth write up probably tomorrow.

    Short answer: Its a bug, and a surprisingly subtle one - for as obvious as your test case makes it, this isn't something that we've hit before.

    Workaround: subclass VLC (note that HLC and NorthSouthContainer will also have this same bug and same workaround), overriding doLayout(). This overriden method needs to do two things - first, call super.doLayout(), and second, set up a deferred command that does... nothing. From Java it would look a little like this:
    Code:
    VerticalLayoutContainer vlc = new VerticalLayoutContainer() {
      @Override
      protected void doLayout() {
        super.doLayout();
        Scheduler.get().scheduleDeferred(new ScheduledCommand() {
          @Override
          public void execute() {
            //do nothing, just make sure we run the scheduler again soon
          }
        });
      }
    }
    To make that work in uibinder, you could make a @UiFactory method that spits out VLC instances, or make a proper subclass of VLC and reference that instead.

    I've moved this to the bugs forum and filed it internally. The fix is simple, I'll be making it in the 3.0 branch so that 3.0.7 will have it as well as 3.1.0. Longer writeup coming soon (but for now, join us in about two hours for discussion on internationalization, split points, and the compiler!

  10. #10
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    57
    Vote Rating
    0
    walkerr is on a distinguished road

      0  

    Default


    Great, glad the example helped. I hacked a fairly direct copy from the code we saw it in, so yes, probably was a bit long winded. Was heading to the airport and short of time, so easiest route was just to keep the UI code the same and remove the model calls.

    Thanks for the quick response on this and the workaround suggestion.

Turkiyenin en sevilen filmlerinin yer aldigi xnxx internet sitemiz olan ve porn sex tarzi bir site olan mobil porno izle sitemiz gercekten dillere destan bir durumda herkesin sevdigi bir site olarak tarihe gececege benziyor. Sitenin en belirgin ozelliklerinden birisi de Turkiyede gercekten kaliteli ve muntazam, duzenli porno izle siteleri olmamasidir. Bu yuzden iste. Ayrica en net goruntu kalitesine sahip adresinde yayinlanmaktadir. Mesela diğer sitelerimizden bahsedecek olursak, en iyi hd porno video arşivine sahip bir siteyiz. "The Best anal porn videos and slut anus, big asses movies set..." hd porno faketaxi