Very slow text selection in Unix builds.

From: Martin Sevior (msevior@physics.unimelb.edu.au)
Date: Fri Feb 28 2003 - 18:42:56 EST

  • Next message: Seth Delackner: "abiconvert project (alpha release for test only)"

    Hi Folks,
            Anyone who has played the unix builds of late knows that selecting
    text is very slow. I've just spent a fair while investigating this with
    --enable-profile builds.

    The problem is definately in the view notification code. If I comment out
    the calls to notifyListeners() in fv_View_protected the text selection is
    nice and snappy.

    I've looked at the gprof output on runs where I select lots of text and
    gprof reports only reports a tiny fraction of total CPU time actually
    used. I looked to see if AbiWord was in sleep state during text selection
    but it wasn't. It was consuming near 100% CPU time.

    I suspect that gprof is not reporting the main CPU usage because it is
    happenning inside glib/gtk somewhere - I'm not 100% sure. It could be very
    slow getCharFormat, getBlockFormat, setSectionFormat calls. I'll
    investigate this next by short circuiting calls to those methods.

    In any case it is not the fault of the nice coloured selection and drawing
    code.

    Cheers

    Martin

    This archive was generated by hypermail 2.1.4 : Fri Feb 28 2003 - 18:49:47 EST