Uploaded image for project: 'Firestorm'
  1. Firestorm
  2. FIRE-20193

Open, de-focussed, active groups, hang the viewer when re-focussed

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: Phoenix Firestorm 4.7.9, Phoenix Firestorm 4.7.10
    • Fix Version/s: Phoenix Firestorm 4.7.10
    • Component/s: Communications, Groups
    • Labels:
    • Environment:
    • SL Avatar Name:
      Beq Janus
    • Reported In:
      Firestorm 4.7.9.50527 Release

      Description

      I have a habit of leaving my viewer for long periods of time. Recently (possibly following the introduction of CoRos) a problem has arisen which can in the worst case force the viewer to log out through missing heartbeats or at the very least hang for a long period of time.

      This appears to be due to the need to process the backlog of text.

      Steps to reproduce
      1) login to SL
      2) open up a busy group (typically Builders Brewery or Firestorm support English will suffice.
      3) say something in the group to ensure that you are properly connected
      4) chat to a friend or two and leave the bust group open but de-focussed.
      5) sleep for 8 hours (go on, it'll do you good)
      6) wake up refreshed and return to your viewer.
      7) click on the busy group and hear your fans spin up and the viewer go unresponsive.

        Issue Links

          Activity

          Hide
          beqphoenixjira Beq Janus added a comment -

          The problem appears to be in updateMessages() called from FSFloaterIM::setVisible() fsfloaterim.cpp

          It will loop through a std::list until it is drained, busily doing its stuff in a self-indulgent manner. Making this some form of Coro may help. I am happy to have a poke at implementing this if others think that this is the right solution.

          Show
          beqphoenixjira Beq Janus added a comment - The problem appears to be in updateMessages() called from FSFloaterIM::setVisible() fsfloaterim.cpp It will loop through a std::list until it is drained, busily doing its stuff in a self-indulgent manner. Making this some form of Coro may help. I am happy to have a poke at implementing this if others think that this is the right solution.
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          It's because the IM windows only get updated if/when they are visible/get visible - in contrast to nearby chat. This might have been done for performance reason or based on a purely arbitrary decision. Changed it in 50964 (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/6d1fda21e59e) that the viewer will automatically update not visible IM windows after 25 pending (unread) messages. Value can be changed via FSMaxPendingIMMessages to fine-tune this if needed.

          Show
          ansariel.hiller Ansariel Hiller added a comment - It's because the IM windows only get updated if/when they are visible/get visible - in contrast to nearby chat. This might have been done for performance reason or based on a purely arbitrary decision. Changed it in 50964 ( http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/6d1fda21e59e ) that the viewer will automatically update not visible IM windows after 25 pending (unread) messages. Value can be changed via FSMaxPendingIMMessages to fine-tune this if needed.
          Hide
          beqphoenixjira Beq Janus added a comment -

          Nice!! I suspect it can afford to go higher than 25 if it is thought that this is a source of lag elsewhere.
          Thanks Ansariel.

          Show
          beqphoenixjira Beq Janus added a comment - Nice!! I suspect it can afford to go higher than 25 if it is thought that this is a source of lag elsewhere. Thanks Ansariel.
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          The actual issue is most likely the append text operation in the chat history. Appending text is always slooooooooooooooooooooow, so the idea was to not have it update on every message, but also not update with a high number that will cause a significant slowdown each time it updates.

          Show
          ansariel.hiller Ansariel Hiller added a comment - The actual issue is most likely the append text operation in the chat history. Appending text is always slooooooooooooooooooooow, so the idea was to not have it update on every message, but also not update with a high number that will cause a significant slowdown each time it updates.
          Hide
          beqphoenixjira Beq Janus added a comment -

          yes I wandered off the path and wa looking at the lltextbase.....that is never gonna be quick

          Show
          beqphoenixjira Beq Janus added a comment - yes I wandered off the path and wa looking at the lltextbase.....that is never gonna be quick

            People

            • Assignee:
              ansariel.hiller Ansariel Hiller
              Reporter:
              beqphoenixjira Beq Janus
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: