Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Suggestions on cause of panel/table resize lag?

    Success! Looks like we've fixed this one. According to our records the fix was applied for EXTGWT-3364 in 3.0.7.
  1. #11
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    Longer writeup:

    The bug appears to have been a typo when using one of the Scheduler methods - instead of scheduleFinally (run at the end of this event loop), or scheduleDeferred (run in the next possible event loop), the scheduleEntry method was used. This method means 'Next time any other code runs, run my code'. To be honest, I'm not entirely sure why GWT includes that method, but they do, and here we are.

    The layout case that causes this is somewhat involved:
    1) a child in a VLC (or NorthSouthContainer, or HLC) which is itself a container, and has -1 set as its height (or width in the case of HLC).
    2) no other code running anywhere on the page including timers, event handlers, rpc responses, etc

    By itself, 1) is somewhat common - the code is supposed to recognize that it is unable to finish the layout this step through the loop, and plans for the next one. That next step then will finalize the layout. 2) is much less common - there are many cases that set up a deferred command in the layout process, so that next time a JS event loop starts, they all will be resolved together. BorderLC, HBoxLC both should trip this off on resize, and any container that holds a non-gxt layout and directly applies a size should hit this as well. For many widgets (and all layouts) simply attaching the widget is enough to cause a deferred command. But if nothing else does set this up, then the layout remains unresolved until an event happens, thus triggering the scheduler to notify the layout that some other code is running, and it may as well run.

    The scheduleEntry call was found in three classes in GXT itself, as well as in an example. It was not intended in any of those locations, and they have all been changed to use the more correct scheduleDeferred.

    This change is being tested carefully and will be merged into the 3.0 branch as well as 3.1 to ensure that teams unable to move directly to 3.1 will be able to take advantage of it. It will be available in SVN this afternoon or tomorrow morning, and will be in the nightly builds that evening.
    Apparently my sencha forum inbox is too small to hold my messages, please contact me at [email protected] to reach me.

  2. #12
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    This has been merged into the 3.0 branch (and automatically into 3.1) and is in the latest nightly builds. It will go out both as part of the 3.0.7 release and as part of 3.1 beta.
    Apparently my sencha forum inbox is too small to hold my messages, please contact me at [email protected] to reach me.

  3. #13
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Thanks for the longer explanation Colin - good to understand the details of the issue.
    Will checkout the SVN and give it a try when back in the office. Appreciate the quick response

  4. #14
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    Consider the nightly builds as well, prebuilt in either our snapshot maven repo, or at support.sencha.com.
    Apparently my sencha forum inbox is too small to hold my messages, please contact me at [email protected] to reach me.

  5. #15
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Just tried the latest 3.0.x nightly build. I'd say this one is improved but not totally fixed. If I leave the mouse outside the window, there's a noticeable delay on the grid size (around 2 to 4s). Before this could be into minutes, so it does catchup significantly quicker but still lags. As before, hover the mouse back over the browser window and it catches up immediately. (Tests were in IE9)

    Edit: Just tried FF, and this has almost no lag

  6. #16
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    Sorry for the delay in getting back to you, its been a busy holiday week and getting busier still as we get ready for GWT.create. As part of our QA for this issue, we built a greatly simplified test sample that still demonstrates the use case:
    Code:
    public class VlcTimingBug implements EntryPoint {
      @Override
      public void onModuleLoad() {
        VerticalLayoutContainer vlc = new VerticalLayoutContainer();
        vlc.add(new Label("Top"), new VerticalLayoutData(1,1));
        SimpleContainer container = new SimpleContainer();
        container.setWidget(new Label("Bottom"));
        vlc.add(container, new VerticalLayoutData(-1,-1));
    
    
        Viewport vp = new Viewport();
        vp.setWidget(vlc);
        RootPanel.get().add(vp);
      }
    }
    This is running at http://qa.sencha.com:8080/test-3.0/t...t.VlcTimingBug - can you confirm that this is resizing instantly, both in FF and IE?
    Apparently my sencha forum inbox is too small to hold my messages, please contact me at [email protected] to reach me.

  7. #17
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Yep - that seems pretty instant in IE and FF.

    The lag we're seeing in IE (noticeable but much less than before) seems to be the right hand side of the grid "snapping" back to the new size with the other columns being resized. Wonder if that's now actually a slightly different cause than the original VLC one?

  8. #18
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    Great, thanks for the feedback. I agree that it does seem likely that either there is a different issue here, or IE is just playing with our minds (you aren't testing this in dev mode, are you?).

    Can you confirm that the issue is still present in the sample you shared? I'll try running your sample again in IE9 to see what else from there might be being deferred. From the description (waiting a few seconds) it seems likely to either be some massive pause in the browser's JS execution, or some browser-specific code going a little too far, though we don't presently do anything like that in the layout containers, and the grid browser-specific code that is timing related is almost always to deal with focus issues, not sizing.
    Apparently my sencha forum inbox is too small to hold my messages, please contact me at [email protected] to reach me.

  9. #19
    Sencha Premium Member
    Join Date
    Jul 2007
    Posts
    79

    Default

    Interesting - thanks for the suggestion. Both IE and FF don't seem to exhibit significant lag on my original cut-down example. So I guess good news on the fix, and I must go back and check our code and layout, see what other factor could be at play here.
    Thanks for the help once again.
    - Rob

  10. #20
    Sencha User
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,737

    Default

    Thanks for the update, we'll look forward to a test sample that demonstrates this issue. Please consider filing this as a new thread, since it will be a different bug with a different fix.

    Some thoughts on hunting this:
    GXT has a ton of extra logging available if you turn it on - enabling the juli logging tools built in to GWT gets you most of the way there, then adding this line to your module will get a bunch of extra logging details about layouts (as well as focus issues, etc):
    Code:
    <set-property name="gxt.logging.enabled" value="true" />
    The reason we build this stuff in is that it rarely makes sense to debug these details - too often the timing issue means that if you pause to debug, you'll miss the issue, or by setting a breakpoint and moving to your IDE, you lose focus, and break the focus issue.

    Finally don't forget that you have the option of a support ticket if you'd like to drop more code on us, or have us join you on a screensharing call. This next two weeks is going to be quite busy for us with the GWT.create conf coming up, but we may either be able to make some time, or follow up afterward.
    Apparently my sencha forum inbox is too small to hold my messages, please contact me at [email protected] to reach me.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •