Announcement

Collapse
No announcement yet.
X
Collapse
  • Page of 1
  • Filter
  • Time
Clear All
new posts
Previous template Next
    #1

    Resizing Components with the browser

    Hi

    We are struggling with our main page resize issues. we would like all our components resize with the browser and yet provide scrollbars when required. Some times the scrollbars appear but the whole GUI freezes on IE. Some times the components don't expand when their parent expands.

    So please give some recommendations and we think in terms how java swing worked in the past. We expect that the layout managers work in the same way.

    Thanks
    Raj
    Neustar
    Tags: None
    #2
    One correction.. on FF it freezes.

    Comment

      #3
      Hi Raj,

      SmartClient's layout managers work similarly to Swing's except that by default they do a lot more autosizing.

      We've just written up with mini-guide for troubleshooting resize-related performance issues. Please try it out and let us know if it leads you to a solution.


      1. Test speed correctly

      When assessing actual speed for end users:

      a. disable Firebug, Fiddler, or other debugging tools. These can have a serious impact on performance

      b. if you have ever enabled SmartClient diagnostic logging in the Developer Console, reset those diagnostic categories to WARN level

      c. close the SmartClient Developer Console when assessing speed


      2. Get rid of native browser scrollbars.

      Native browser scrollbars cause an interaction where, when resizing smaller on either axis, the browser may temporarily show and hide scrollbars that will ultimately be removed, causing SmartClient to resize the whole UI multiple times to accomodate those scrollbars.

      To remove native browser scrollbars, add overflow:hidden to the <body> element:

      <body style="overflow:hidden">

      This can also be done via CSS:

      body { overflow:hidden }


      3. Set fixed-size elements to fixed size

      Many components, including V/HLayouts and V/HStacks, are overflow:"visible" by default, which
      means that SmartClient will autosize to their content.

      If such components are in fact fixed size, it simplifies Layout calculations to set them to
      their fixed size and set overflow:"hidden" instead.


      4. Set resizeable components to overflow:"hidden"

      If the user should be allowed to use resizeBars and similar UI elements to resize a Layout as
      small as they wish, it likewise helps to set the layout to overflow:"hidden" instead. If you
      want a fixed minimum value for resizing via resizeBars, you can set layout.minHeight and
      layout.minWidth rather than relying on autosizing to impose a minimum.


      5. Set reasonable default sizes for autosizing components

      If a component really should autosize, for example, a form should be as tall as it needs to in
      order to show all items, set it's size to a reasonable guess of it's final rendered height.

      For example, the defaultHeight of a DynamicForm is 20 pixels in most skins, the height of a
      typical FormItem. 60 pixels is a reasonable default for form with 3 rows of items.


      6. Verify basic layout structure

      Use the Watch Tab in the Developer Console to inspect your component tree. Be sure to enable
      the "hidden" and "generated" and "undrawn" checkboxes to see the full tree. Look for places
      where you may have, for example, generated 1000 components where you intended one. It happens.


      7. Ensure incremental rendering is enabled on larger grids

      ListGrids and TreeGrids that contain many pages worth of data should be using incremental
      rendering. The setting showAllRecords:true disables incremental rendering and can be used for
      smaller grids, but if enabled for large grids where it greatly slows redraw time, and hence
      page resize time.


      8. Investigate remaining redraws caused by resizing

      In the Developer Console, enable the "redraws" log category and resize the browser once,
      quickly releasing the drag. If you see a repeated pattern of groups of redraws, these are
      caused by repeated attempts to match the browser's new size during an extended drag, and you
      should focus in on just one set. Alternatively, use keyboard shortcuts or programmatic resize
      of the browser to ensure you are looking at redraws for only one browser resize.

      If you have components such as a DynamicForm or ListGrid that fill available space, it's normal
      for them to redraw once. Multiple redraws for such a component may indicate that it's size is
      affected by a component that autosizes (see #3,4,5 above).

      If the cause of extra redraws is not clear, enable the "layout" diagnostic category and inspect
      the diagnostic output for the Layout containing the component that is redrawing, and the
      diagnostic output for parent layouts. Each Layout will report the reason for each layout run,
      the reason the Layout is assigns specific sizes to each member.

      The Layout will also report events such as "overflows", meaning that an overflow:"visible"
      member was not able to take on the size that the Layout specified, and the Layout had to rerun
      sizing calculations. Overflows can be avoided via steps #3,4,5 above.


      9. Audit size-related event handling and overrides

      Inspect any code that overrides or observe()s resizeBy(), resized(), layoutChildren(),
      setRect() or other sizing-related methods. Check for:

      a. forgetting to call Super()
      b. not returning appropriate return values
      c. expensive calculations: use log statements to understand how often you're code is being
      called
      d. sizing other components in such a way that a loop is created

      A common mistake is to override resizeBy, call Super() but not *return the value returned by
      Super*:

      Code:
          // WRONG
    resizeBy : function () {
       this.Super("resizeBy", arguments);
       doSomethingElse();
    },
      The return value of resizeBy() reports whether the component actually resized, and is key to
      allow many layout algorithms to properly no-op (take no action) when a resize has no effect.

      Code:
          // Correct
    resizeBy : function () {
       var returnValue = this.Super("resizeBy", arguments);
       doSomethingElse();
       return returnValue;
    },
      10. Remove extraneous nesting

      If you still have a problem, consider whether you have a large of number of extra Layouts or
      other containers that have no function. For example, Layouts with only one member, or nested
      Layouts where the members array could be combined with no change in functionality.


      11. Isolate the problem

      Finally, if you still have issues, you probably have some kind of non-obvious bug. Check your
      basic assumptions and try to simplify your application until the problem disappears. If this
      doesn't yield an answer, take the simplified version of your application, ensure that it can
      run in an unmodified SmartClient SDK, and post it to the SmartClient Forums or seek help
      directly from Isomorphic.

      Comment

        #4
        What we found was that it wasn't freezing but it was taking so much time to get back the focus. In the meanwhile user were not able to enter into the form after have scrolled and thus assumes it was stuck. The cursor is gone while the user is looking for the cursor blink. After a long time , I can type again.

        As I said this is happening on FF2/3 on Linux/Win while on Mac this is not an issue.

        What we have is a menu pane (Using a tree widget) on the left and form content window on the right. Clicking the tree node opens windows on the right side. We are allowing only one window to be viewed at one time by hiding and showing the other windows. A kind of classic thick application you normally see on the desktops.

        For now we seemed to have solved the problem with the browser scrolling and setting the default overflow for all components. Now as a scroll, my left menu is out of the view which is not a ultimate solution.

        The user base is using different resolution monitors - the minimum we support is 1024x768 but our staff has better monitors. Setting the fixed size for components make them appear too small and the users are typically asking for increasing the size as they see plenty of space on todays wide monitors.

        Comment

          #5
          Hi rakmineni,

          Your slow resizing is probably due to the fact that components that have been hidden may still be resized and can contribute to a slow resize. It's probably better to clear() the Windows which are not shown rather than only hide() them. Another approach is set to set them to a fixed size and move them offscreen. Sounds like this is a good one to add to the tips.

          As far as the tips themselves, we do not suggest creating a fixed layout, step #3 suggests that if a component *is intended* to be fixed size, that you assign it a fixed size.

          There's no reason to settle for your current workaround - applying the suggested techniques will solve the problem.

          Comment

            #6
            It sounds like there is a lot of good information on dealing with resize performance issues in this thread, but it is almost 6 years old. Is there anything more up to date or is this the latest?

            Comment

            Previous template Next
            Working...
            X