Closed Bug 53051 Opened 25 years ago Closed 25 years ago

tree widgets are dead slow.

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jud, Assigned: hyatt)

Details

I can't use mail because tree widget scrolling and header selection are too slow.
nominating beta3. product is not usable w/ out this.
Keywords: dogfood, nsbeta3
*** This bug has been marked as a duplicate of 26137 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Oops, that wasn't the same.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Status: REOPENED → ASSIGNED
Tree widget scrolling/redraw is one of the main reasons I don't use mail/news on a regular basis (and will probably end up finding a different Unix mailer to use so that I can use mozilla as my browser without having to run mozilla and 4.x simultaneously). There have been various bugs filed on this -- 18739, 21592 -- but they keep getting closed as "it's good enough". The mail thread pane is still unusuable on linux.
The big problem is that we're pretty much out of easy options for improvement. Any additional work will have to be more drastic, i.e., using random access on the content model and other very large tasks. The problem being of course that random access involves heavily modifying every layer (mail/news, RDF, sorting, the XUL content model, and the front end tree frame code) and would be a multi-engineer effort. It's never been approved as being something that could be done in any reasonable timeframe, given all the other problems. As much as I'd love to spend all my time trying to fix this, I know that's not a practical possibility before 6.0.
Just out of curiosity, do we know why it's unusable on Linux? It's good enough (though not snappy) on Windows (PII/400 laptop) and we don't have random access to the content model on Windows. Is it possible there's a platform-specific problem at hand?
I believe it's painting. I believe at one point we established it paints more than it is supposed to on Linux, or that painting of images was slower than it should be. Pav, do you remember this?
Another problem Linux has with scrolling is that it generates 2-3 times as many events during a scroll as Win32 does (and therefore does 2-3 times the work).
i was scrolling the other day, and we seem to be painting the correct amount. I am having problems making quantify run on solaris, but i'm working on it.
Is this bug filed against the *product* (i.e., optimized commercial builds) or debug builds, or do you consider both too slow to use?
both.
*** Bug 52149 has been marked as a duplicate of this bug. ***
Ok, some style rules went in that massively regressed the tree. I have filed a bug to have those rules backed out. The bug is assigned to hangas.
So is this a dup of bug 53091 (the new one hyatt just filed)?
perf should be improved after fix to bug 53091. nsbeta3-/future. reopen if not the case.
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
Adding myself to CC (I was on bug 52149, now a dup of this). I'll re-run my checks under FreeBSD/X11 to see how much the fix to 53091 has helped.
Has Hangas' repair pulled this below the dogfood radar, or should this still get the plus?? The comments at the end leave this all in question. Adding NEED INFO to make dogfood-plus/minus call.
Whiteboard: [nsbeta3-] → [nsbeta3-][NEED INFO]
I checked. FreeBSD 4.1 20000919xx No joy. On my old machine (PIII-450), scrolling a full-height (~45 lines) Manage bookmarks window takes 6-10 second for a page-up or down. (6 normally, 10 on the first scroll). History is likewise very very slow with windows opened more than a few lines. On a PIII-800 w/ 133MHz ram, it only(!) takes 2-3 seconds to scroll manage bookmarks one page. Verification from someone on Linux? Use a tall window for History or Manage Bookmarks. Performance on scroll degrades exponentially depending on the size of the window. Removing NEED_INFO. Resetting Target from Future to nothing Resetting severity to major renominating for nsbeta3 as per trudelle's comment.
Severity: normal → major
Whiteboard: [nsbeta3-][NEED INFO]
Target Milestone: Future → ---
Please open bugs for specific problems that exist with the tree widget. The particular problem that Jud noted has been fixed (bug 53091). I will reopen bug 52149 that is a specific case, for bookmarks, on BSD. Resolving this one as WFM.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
I should note that bug 52149 applies to all tree widgets; or if you prefer, all tree widgets have an exponential slowdown in scroll as the display window is made taller. Bookmarks is slower to begin with and so it's more noticable, but History and other tree views show the same thing. I've made a comment to this effect in bug 52149. I should also note that whatever fix was made for this bug and bug 53091 does not solve the exponential slowdown problem. Timing for page up/down remain in the seconds(!) on a PIII/800 for reasonable window sizes. Further discussion should be in bug 52149, which was reopened.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.