ben.bucksch at beonex.com
Tue Mar 28 04:23:30 UTC 2017
Robert Kaiser wrote on 27.03.2017 21:48:
> Ben Bucksch schrieb:
>> Matt Harris wrote on 24.03.2017 18:27:
>>> /I think all this relies on a powerful replacement for the XUL
>>> treeview. Do we have one now?
>> Indeed, this is needed.
>> I've once found a "fast-list" or similar on github, that goes in that
>> direction. But no, we don't have it now. As mentioned, I have a plan
>> how to do it, but I haven't realized it yet. That's one of the things
>> we'd need to create as part of the framework.
>> That problem is inherent, because the XUL <tree> widget was
>> originally written specifically for Thunderbird. Firefox didn't need
>> it. And it might also go away now, if Firefox doesn't need it anymore.
> FWIW, I think a lot of the web would profit from a widget like that -
> so if we can implement something like it as e.g. a web component, I
> think there may be some interest in taking this as a base for a web
> standard with an in-browser widget in the future - IMHO, this is one
> of the biggest pieces HTML is lacking to become a really useful UI
> language nowadays.
There are many HTML tree widget implementations out there, but most fail
when you start pushing 100000 entries in there. The problem is that most
create a DOM nodes for every line and cell, and once you get to a
million DOM nodes, that's a noticeable load time and costs RAM. For
Thunderbird, we need to render folders with tens of thousands and a
hundred thousand emails.
I had mentioned that I had an idea how to implement it. I had not tried
it out, so I did that now.
Here's a prototype. This is just a start. It doesn't contain tree
functionality yet, just a table. The tree functionality would be added
on top. There are also many things to be polished: Alignment, fixing
column width to not change while scrolling etc..
But the basic idea of a fast list is working. It's loading 100000
entries on load, and you can add 100000 more on a button click. You will
notice that the addition is very fast. More importantly, scrolling is
very fast. Scrolling should work both using the scroll bar and using the
Try it out: http://benbucksch.github.io/trex/fastlist-test.html
How did I do that? The basic trick is that I don't create DOM nodes for
every rows, but only for the 10 or so visible rows. The data is in a
pure data array. When the user scrolls, I do not move or destroy DOM
nodes, but merely replace their text content and leave the nodes in
place. I then listen to mouse wheel scroll events, and scroll
correspondingly. The scroll bar at the right is a dummy element, and I
set the inner height of it to the calculated height in px that the rows
would have, if all rows would be DOM nodes. Then I listen to scroll
events again, and translate them to corresponding row content changes.
From what I understand, that is the basic principle that XUL <tree>s
also work with. Just that XUL <tree>s are implemented in C++, and I
painful part in it.)
The coolest thing is that we're no longer limited to a single line per
row, and we can have rich HTML content in each cell. XUL <tree>s can do
neither, and that's a major limitation. We've always wanted to make the
message list prettier, but we couldn't. Now we can.
As said, there's a lot more polish to be done, but this is a proof of
concept that this works.
More information about the tb-planning