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.

        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: