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 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. 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. The RuledCanvas would basically be an array of HorizontalBoxLayouts, and scrolling would put new content into those layouts. (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. 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, 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! 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. 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
