Jetspeed 2
  1. Jetspeed 2
  2. JS2-755

Desktop Pipeline: Blank deley when switch page

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.2
    • Fix Version/s: 2.1.3, 2.2.0
    • Component/s: None
    • Labels:
      None
    • Environment:
      Tomcat5.5, IE6 and FF2.0.0.4

      Description

      When I shifted from one page to another, say from 'registration' to 'Welcome to Jetspeed 2', there is a short blank delay (i.e. while the 'welcome to jetspeed 2' tab is on focus right after clicking the tab, the content shows blank from some 2 to 3 sec. before all portlet fragment start to show (start with loading... on the portlet action bar and then full contents...)).

      1. JS755-2.diff
        9 kB
        Woonsan Ko

        Activity

        Yang Sie created issue -
        David Sean Taylor made changes -
        Field Original Value New Value
        Assignee Steve Milek [ smilek ]
        Steve Milek made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hide
        Woonsan Ko added a comment -

        I'm not an expert on DOJO or AJAX, but I traced this problem a little bit.
        I think the main thing to make delays is creating portlet window widgets. I don't know how we can improve the performance of creating widgets.

        However, I think we can make it look faster by changing processing orders, like the following:

        • The current core.js creates all portlet windows first and renders all later.
          If we create and render one portlet window first and move to next one, then it can look faster. (Actually it's not faster though.)
        • Also, if we render portlet windows ordered by row first, column later, then users can see the upper portlet windows before all portlets are rendered. We can render some portlets during user's thinking time.
        • The current version shows all portlet windows almost at the same time.
          If we create and render portlet windows one by one without relieving the browser's rendering engine, the browser will show all portlets almost at the same time.
          However, if we relieve the browser by using window.setTimeout() function to render a portlet window, then the browser can render portlet windows one by one properly.

        I wrote a patch and attached on this.

        Please give me any comment. Thanks!

        Show
        Woonsan Ko added a comment - I'm not an expert on DOJO or AJAX, but I traced this problem a little bit. I think the main thing to make delays is creating portlet window widgets. I don't know how we can improve the performance of creating widgets. However, I think we can make it look faster by changing processing orders, like the following: The current core.js creates all portlet windows first and renders all later. If we create and render one portlet window first and move to next one, then it can look faster. (Actually it's not faster though.) Also, if we render portlet windows ordered by row first, column later, then users can see the upper portlet windows before all portlets are rendered. We can render some portlets during user's thinking time. The current version shows all portlet windows almost at the same time. If we create and render portlet windows one by one without relieving the browser's rendering engine, the browser will show all portlets almost at the same time. However, if we relieve the browser by using window.setTimeout() function to render a portlet window, then the browser can render portlet windows one by one properly. I wrote a patch and attached on this. Please give me any comment. Thanks!
        Woonsan Ko made changes -
        Attachment JS755.diff [ 12364775 ]
        Hide
        Yang Sie added a comment -

        Thank you Woonsan on commenting on this issue. Correct me if I didn't grasp the guts of your suggestion... My question to you is that if we render portlets one by one row by row, is that still async rendering? say, assume the first portlet in the first row gets data fast and the user is happy there. The second portlet in the first row needs to call a webservice and somehow that web service takes 20 seconds to come back with data. Does the user have to wait for that long to see the second portlet contents before s/he sees contents in all other portlets (or even other portlets start rendering)? In another word, is this a client side sequential rendering? Please advise. Again, thank you for looking into it and your kind help.

        Show
        Yang Sie added a comment - Thank you Woonsan on commenting on this issue. Correct me if I didn't grasp the guts of your suggestion... My question to you is that if we render portlets one by one row by row, is that still async rendering? say, assume the first portlet in the first row gets data fast and the user is happy there. The second portlet in the first row needs to call a webservice and somehow that web service takes 20 seconds to come back with data. Does the user have to wait for that long to see the second portlet contents before s/he sees contents in all other portlets (or even other portlets start rendering)? In another word, is this a client side sequential rendering? Please advise. Again, thank you for looking into it and your kind help.
        Hide
        Woonsan Ko added a comment -

        Yes, it is still async rendering, and it is still client side parallel rendering, of course.
        I just suggested that it would be better to put portlet windows one by one, row by row.
        There's no difference on asynchronous DOJO bindings between the existing and my suggestion.

        The existing implementation works like the following:

        • Reads psml.
        • Creates all portlet windows.
        • Renders all portlet windows. (Iterates all portlet windows and invokes DOJO binding, which makes asynchronous call. That is, it invokes sequentially, but retrieves portlet contents asynchronously by using asynchronous DOJO binding.)

        My suggestion works like the following:

        • Reads psml. Register a timer.
        • [LOOP until there remains portlet windows]
          When it is on timer, create a portlet window and render the portlet window. Register a new timer.
        • Of course, rendering means invoking asynchronous DOJO binding, so it renders asynchronously.
        • Why timer using window.setTimeout()?
          If we create and render in a loop without timers, then browsers have a difficulty to get a chance to render UI. In that case, all portlet windows look rendered at the same time. So I think we should relieve browsers by using window.setTimeout().

        During my testings with my patch, I got the following approximate figures:

        [Test scenario]
        In the '/jetspeed.psml' page, click the '/default-page.psml'.

        [Firefox 2.0.0.6]
        The existing: 12 sec. to show all portlet windows. (All portlet windows were rendered almost at the same time.)
        My patch: 2 sec. to show upper 4 portlet windows. 8.5 sec. to show all portlet windows.
        Also, it shows the first portlet window faster.

        [IE 6]
        The existing: 13 sec. to show all portlet windows. (All portlet windows were rendered almost at the same time.)
        My patch: 5 sec. to show upper 4 portlet windows. 14 sec. to show all portlet windows.
        Also, it shows the first portlet window faster.

        Thanks!

        Show
        Woonsan Ko added a comment - Yes, it is still async rendering, and it is still client side parallel rendering, of course. I just suggested that it would be better to put portlet windows one by one, row by row. There's no difference on asynchronous DOJO bindings between the existing and my suggestion. The existing implementation works like the following: Reads psml. Creates all portlet windows. Renders all portlet windows. (Iterates all portlet windows and invokes DOJO binding, which makes asynchronous call. That is, it invokes sequentially, but retrieves portlet contents asynchronously by using asynchronous DOJO binding.) My suggestion works like the following: Reads psml. Register a timer. [LOOP until there remains portlet windows] When it is on timer, create a portlet window and render the portlet window. Register a new timer. Of course, rendering means invoking asynchronous DOJO binding, so it renders asynchronously. Why timer using window.setTimeout()? If we create and render in a loop without timers, then browsers have a difficulty to get a chance to render UI. In that case, all portlet windows look rendered at the same time. So I think we should relieve browsers by using window.setTimeout(). During my testings with my patch, I got the following approximate figures: [Test scenario] In the '/jetspeed.psml' page, click the '/default-page.psml'. [Firefox 2.0.0.6] The existing: 12 sec. to show all portlet windows. (All portlet windows were rendered almost at the same time.) My patch: 2 sec. to show upper 4 portlet windows. 8.5 sec. to show all portlet windows. Also, it shows the first portlet window faster. [IE 6] The existing: 13 sec. to show all portlet windows. (All portlet windows were rendered almost at the same time.) My patch: 5 sec. to show upper 4 portlet windows. 14 sec. to show all portlet windows. Also, it shows the first portlet window faster. Thanks!
        Hide
        Woonsan Ko added a comment -

        I pasted the original debugging codes and improved the logic that checked if there's any remaining portlet windows, row by row.
        I'm uploading a new patch file and I'm going to remove the old attachment.

        Show
        Woonsan Ko added a comment - I pasted the original debugging codes and improved the logic that checked if there's any remaining portlet windows, row by row. I'm uploading a new patch file and I'm going to remove the old attachment.
        Woonsan Ko made changes -
        Attachment JS755-2.diff [ 12364865 ]
        Woonsan Ko made changes -
        Attachment JS755.diff [ 12364775 ]
        Ate Douma made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Steve Milek
            Reporter:
            Yang Sie
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development