The regression below suggests that it would be valuable to have a subset of the editing layout tests run by the build bot in a PLT sort of fashion, to check for editing perf regressions.  There would need to be a some cases added that used large documents (for ops like load, insert, paste, delete, move cursor, change selection, change style, undo,...).

It's not something I'm game to tackle right now, but I thought it might be worth adding to the editing project page, as someone might find it a nice size intro to some of the tools.  I bet it would catch bugs.

trey

(And ugh, I wonder why does all the styling get lost when I forward this checkout email message, but gets kept when I copy/paste it...)



Begin forwarded message:
Date: May 2, 2006 4:56:40 PM PDT
Subject: [webkit-changes] [14165] branches/Safari-2-0-branch/WebCore

Revision
14165
Author
thatcher
Date
2006-05-02 16:56:37 -0700 (Tue, 02 May 2006)

Log Message

        Merged fix from TOT to Safari-2-0-branch

    2006-03-20  Justin Garcia  

        Reviewed by darin

        

         

        REGRESSION (Mail): Mail takes half of forever to paste >1500 lines - replaceSelectionWithNode

        * dom/Position.cpp:
        (WebCore::Position::upstream): Avoid calling previous() when we know that 
        it will 1) end the search and 2) be expensive to compute.
        (WebCore::Position::downstream): Removed some dead code.
        (WebCore::Position::inRenderedText): Return false for offsets inside composed characters.
        * dom/Position.h:
        * editing/VisiblePosition.cpp:
        (WebCore::VisiblePosition::init): If there are two visually equivalent candidates, we choose
        the one that occurs first in document order.  Using upstream() to find the one that occurs first is
        much faster than the old code.

Modified Paths

Diff


_______________________________________________
webkit-dev mailing list
[email protected]
http://www.opendarwin.org/mailman/listinfo/webkit-dev

Reply via email to