[EMAIL PROTECTED] schrieb: > Sebastian Werner <[EMAIL PROTECTED]> writes: > >>> Due to the inability to calculate arbitrary sized widgets' layed-out size, >>> I'm currently considering a virtual "Ruled Canvas" widget. A Ruled Canvas, >>> like ruled paper, has a fixed number of rows of a fixed height and width. >>> This makes it similar to the Table widget, but with some significant >>> differences: - In a RuledCanvas widget, widgets are placed into rows, >>> whereas in the Table widget, the value placed into a cell is (typically, at >>> least) HTML. By having widgets placed in the rows, all of the advantage of >>> qooxdoo widgets is retained (e.g. events, automatic sizing, etc.) >> I think to keep auto-sizing is just to slow. And to handle events and >> widgets internally, just to repeat myself, also means to create thousands of >> instances of at least QxWidget. But one major reason to handle large >> datasets virtually is, especially regarding IE's large problems with many >> objects, is to omit objects. > > Sebastian, thanks for your comments! > > We don't need to keep thousands of widgets, but we do need to keep some.
I don't know why to keep these "some". The most features of qooxdoo widgets are just not usable nor useful inside a virtual rendering area. For example events and other data attached to widgets. In my opinion widgets are just to slow and fat for a highly dynamic area like these. > I > think you may have misunderstood how I wanted to use the data passed to the > RuledCanvas by its user (e.g. Tree). The Tree would not create the widgets > for all nodes initially. Instead, it would save the information required for > the node, e.g. its icon paths, label, etc. as metadata. OK, this is the second possibility. If you use widgets or not you must always store these informations inside a model - if possible. > An array (possibly) > of this per-row metadata would be provided to the RuledCanvas which would > determine when a particular row needed to be displayed, at which time it would > generate the widgets required for that row or, more likely, call a function in > the Tree class, passing it the metadata for the row and a horizontal box > layout for the row, and the Tree class function would generate only the > widgets needed for that row. One issue with this is for example that the widgets are designed to work on a node-basis, while virtual areas are only fast enough if they dump the complete HTML in one action to the parent DOM node. Are you sure you really need such advanced features e.g. layout managers, events, color themes, etc. directly in each cell/row for example. I think this is just overhead. The major priority for such (virtual) widgets should be performance and not features. (As long as not everybody is sitting there with a 10 Ghz machine ;)) > > The RuledCanvas would basically be an array of HorizontalBoxLayouts, and > scrolling would put new content into those layouts. This means, you must update the properties and you issue the layout system to apply these updates. I don't think we reach the required performance using this method. > (Whether that's done by > removing stuff from existing layouts and adding new stuff, or by refreshing > the entire area by generating all new stuff is an implementation detail.) > Therefore, in general, only the widgets for displayed portions of the tree are > actualized, so there aren't thousands of widgets hanging around, only the few > that fit on the visible page. Yes, OK. But that doesn't give us the performance of simply array-concat and innerHTML. Especially in this area, where you normally update the whole content more often than parts, there isn't any alternative to innerHTML. And it's not just this. All the features of Widget are just to feature-rich and this way slow to get it implemented this way in a acceptable way. > > Now the exception to the general rule that only the widgets for displayed > portions of the tree are actualized is that the top-level Tree node must also > be actualized even if not currently displayed. That node receives events, and > must be listening for them. > > Folders receive open/close events on themselves, but that can typically only > occur if they are displayed. (It would be possible for an application to > issue open/close events to non-displayed nodes, so the virtual Tree would > either not be an appropriate widget to use in that case, or it would have to > handle modifying the metadata. The latter is preferable, and probably > doable.) > >> In my opinion a virtual renderer is just comparable to the other renderers in >> the new version. I think about renders like these: >> * Text (supports auto-sizing) >> * Image (supports auto-sizing) >> * HTML (supports auto-sizing) >> * Iframe (does not support auto-sizing) >> * Flash (does not support auto-sizing) >> * Children (can use different layout-managers, supports auto-sizing depending >> on selected layout manager) >> * Virtual (can render html content dynamically, supports multiple renderers >> (which are not layout managers, but simple HTML providers), does not support >> auto-sizing!) >> ... >> >> I want to combine all these stuff in the new layout implementation of qooxdoo >> ~0.7. > > That sounds great. I'm likely to want an implementation of a virtual Tree > ages before 0.7 is out, Interesting plan. In my idea a virtual tree must be a complete rewrite of the current one. So I don't think this is easily possible. > so if it looks like the virtual renderer will handle > other cases, I may concern myself primarily with a virtual Tree. If my > continued thinking about this yields a good general solution, then it'll be a > good stepping stone for future 0.7 work. > >> In my tests, it's better to render a table completely and replace it's >> complete content instead of update single rows or even cells. If you scroll >> your widget for example you must replace each row (or whatever is used >> here). In my experience over the years, many single updates are much(!) >> slower than one larger update. In some basic tests a update of a complete >> table took 10-20ms in both browsers, IE and Firefox. This way the scroll >> performance was better than seen anywhere else in qooxdoo yet. This method >> could also used to change the selection and so on. It must just be highly >> tuned for performance. > > Your experience at javascript performance issues likely outweighs mine by > orders of magnitude, so you can bet I'm listening! That's the kind of > response I was looking for when I posted about this, so thanks! Ok, well. qooxdoo rocks ;) > > Having been continuing to think about this, I'm now considering a modified > implementation which uses an abstract RuledCanvas as a superclass of Tree > instead of as a renderer for the tree. In that way, the double-process of > render/generate widgets/render is eliminated. I haven't yet flushed this out > in my head yet, so more detail will have to wait. It may obsolete many of > your concerns, though, if it works as I'm thinking. I would like it better to start working on the new layouter as early as possible. What's your idea of a 0.7 release date? Or in what time frame do you think you can build an own virtual tree? Cheers, Sebastian > > Thanks again! > > Derrell ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
