Opinions on variable row heights?

[Andrew S. Townley]

Hi. Me again. :)

One of the reasons that I found SlickGrid was because I was annoyed that
the XUL table requires fixed row heights. Even though SlickGrid does
too, it still seems to be the best choice I've found to move my UI from
XUL to regular XHTML.

However....

One of the main reasons I want to display things in an editable grid is
that I show values that might contain large blocks of text that I'd like
to have the user edit in place. I've a workaround for this at the
moment in the UI, but it's ugly and somewhat complex to manage.
Ideally, I'd like to have the option of setting an option like
rowHeight: auto; max-height: XXX; min-height: XXX; and then letting the
browser figure out the right size within those constraints.

Having had a good look through the SlickGrid code now, I realize this
will potentially have a huge impact on performance since everything will
need to dynamically calculate the positions of the rows. However, I
think that it would be possible for the option rowHeight: (auto | fixed)
to be implemented in a way that would still avoid the performance hit in
fixed mode.

This is something I intend to come back to after I've ported/implemented
the remainder of the UI as a "pass 2" phase, but it is something that I
really need in my application.

As an implementation strategy, I see two potential options:

1) Add special properties like row["slick.rowHeight"] and
row["slick.rowsHeight"] to each row object, or

2) Maintain a parallel array of row properties objects to keep track of
these things.

I think that each row should at a minimum be required to track it's
height as part of this change, and I'm thinking that it might be useful
to also track the overall cumulative height of the rows to a particular
row. This second value would need to be recalculated when rows are
reordered, but I'm not sure how often that happens in practice with
large data sets (at least on purpose). ;)

Are there any opinions on this type of functionality?

I'm happy to have a go, but I'm not sure exactly when I might be able to
get to it. There's a lot of application functionality that I need to
implement as part of the WebUI port, and initial functionality is a
higher priority than UX at the moment.

Does anyone else need this feature? Is there a better approach to
implementing it and maintaining adequate performance?

Cheers,

ast
--
Andrew S. Townley <a...@atownley.org>
http://atownley.org

[Michael Leibman]

That's a pretty complicated topic.

I'll say right away that I don't think there are any good solutions to that.

It is possible to do what you're suggesting and keep track or ever row's height and the total height of all preceding rows.  One issue is, as you've pointed out, a significant recalculation overhead whenever the data changes.  The other issue, and a more important one as far as I know, is that the decision of what a row height should be can only come from the browser's layout engine.  That means that whenever rows are added one at a time, they first have to be added to the DOM, the browser has to do lay out, we query the height, reposition, update the heights cache.  That negates all of the optimizations that browsers do right now that enable us to append rows so quickly - more specifically, the layout, css pass & rendering can no longer be delayed until after we're done manipulating the DOM.

[Andrew S. Townley]

Hi Michael,

Yeah, you make some good points. I knew it would blow a hole in your
optimizations based on what I saw in the code.

Maybe I'm being naive, but I think that if you were really going to do
thousands of rows (at least at once), then you'd know something about
the data you were going to display and be able to guess well enough to
use the fixed row size that's already in place. If you didn't, then you
either buy a different grid for ~$200 or you'd use a regular table with
a different editing scheme than is used in the SlickGrid.

I'm not that excited about most of the commercial solutions I've seen
for many of the same reasons you pointed out in your description of why
SlickGrid works the way it does.

At least in my scenario, while there might be bazillions of rows
eventually, they would only come in chunked at about 20-100 at a time.
By the time you got to more than that, the user would likely give up
because there was just too much data to digest at once.

I don't have any performance benchmarks, but do you think that in this
scenario that the obvious performance hit would be as bad as you
describe?

The last thing I would like to do is try and re-develop browser layout
code for dynamic content. Other people are doing the
"browser-in-a-browser" thing, but I don't think that's really necessary
here.

I'm fully aware that it will be slower than the fixed row heights, and
maybe it'll be unbearably slower, but certainly this functionality is
one of the things that people who've implemented custom grids have
added. I think there's just too many valid use cases for using the core
data model/renderer/editor approach in SlickGrid on smaller sets of
dynamic sized rows to ignore (but it's not my project ;) ;)

Like I said, it would be ideal to have it right now, but I've a bunch of
other bits of functionality to occupy my time for the next couple of
months, so I won't get a chance to tackle it. However, I do need it and
I don't want to start from scratch, nor do I really want to go off on a
tangent that nobody involved with SlickGrid thinks is important.

I was actually surprised that this question hadn't come up before, but I
didn't see anything relevant on Google. We can leave it be for now, but
I did want to toss it out there to see what other people thought.
Thanks for your thoughts.

Cheers,

ast

[Michael Leibman]

On your first point, I do think that it is a rather naive assumption.  

The pure rendering performance impact might not be THAT bad, but this isn't what concerns me the most.  One of the key areas where SlickGrid really shines is its ability to do extremely fast updates for changes in the data (since only the changed rows in the viewport need to be updated).  Having variable row height would mean that everything after the affected rows has to be recalculated.

As for smaller and less interactive data sources... well, I don't think SlickGrid is the best solution.  The architecture and design principles behind it may appeal to you, but as far as pure features and project maturity, it still has a long way to go.  Something like ExtJS may be a better option.  I created SlickGrid to fill a void in available grid components and I am trying to keep the focus on doing what no other grid can.  It is a flattering thought to excel in all uses, but it is more than I alone can produce.  This is where you (and other supporters and contributers) come in :)  My advice would be to create a prototype and explore this functionality more.