Last week we announced that we are starting to work on a general infrastructure for virtual widgets. We have received very positive and constructive feedback for this project. Today we presented our first ideas for the virtual widget infrastructure to the qooxdoo team.
[slideshare id=941936&doc=going-virtual-1232637281815184-1&w=425]
Our basic idea is to have a strict separation between rendering and interaction. We want to provide a set of basic components, which can be used to create very different virtual widgets. The core of this framework will be the virtual scroll pane. The pane contains a set of layers, which contribute different parts of the rendered view. A layer is responsible to render one aspect of a given range of visible cells. Layers can e.g. be used to render row background colors, grid lines or the cell data. They are designed in a way, which makes it easy to write custom layers for special purposes.
One interesting experiment is a layer which uses real qooxdoo widgets to render the cells. First tests show that the scroll performance is adequate if the number of visible cells is not too high. This is very exciting because it offers a whole new set of use cases. As proof of concept we hacked together the user interface of an instant messenger application.
The interesting fact about this demo is that the performance is not limited by the size of the buddy list. The startup and scroll speed is exactly the same no matter whether the messenger contains 20 or 2000 contacts.
We are still exploring the possible uses of such a framework so if you have any ideas we’d like to hear about them.
Really impressive stuff, guys.
Especially like the chat idea with different row heights. Well done!
Mhh, not so sure if this really scales well on all systems, though. The messanger has a loading time of 10 seconds for me… somehow waiting for something to load. First I see a frame, then the text and after these magic 10 seconds the icons as well. Somewhat crazy. (Tested in Safari 3.2.2/Mac).
Still miss some kind of simple demo. In the previous discussion we talked about starting with simple demos of most used things first.
By the way: I would really like to have the options to scroll full rows only. It just flickers to much in my eyes to handle text on all kind of offsets. Full row scrolling like in iTunes, Apple Mail, Outlook etc. would be a benefit (would say that it also would be a good default
)
I would also like to see a collapsable tree or grouping in the virtual view. For example closing the ‘Friends’ group of the chat window.
Also would like some API insides in the next posts
Please keep up your good work.
Great stuff, guys. Works really fast! Thanks for your work on it.
@Sebastian, don’t see any problems in Safari 3.2.1, Mac, works very very fast. I’m really impressed.
Yes, seems to be better now. Mhh, maybe something server related.
The really cool thing I don’t get the first time is that when using widgets to render you also have all these neat features like appearance, flexible resizablity (with ellipsis) and all kind of stuff. This idea rocks. Just wonder why the Object Inspector do no show many widgets. Seems I must have a look at the code
@Sebastian
I don’t see the delay either. For me the demo starts up very fast.
We have some simple demos as well. Check out the online demo browser. Right now some demos are still broken but expect them to be fixed by this afternoon. We created the messenger demo mainly to verify that our ideas work in a real life example. The code is still a hack but it shows that we are on the right track.
I have added your suggestion to do full line scrolling to our feature list.
FWIW, here the load speed is totally acceptable (not noticeable) but the scroll speed (when dragging the scroll knob) is disappointing. One way to make it look more responsive would be to decouple the visual refresh of the scroll bar (which should be updated immediately) from the one of the pane. The same problem is present on the Huge table demo.
Also, I’m not convinced yet about the multi-layer idea *if* the cells are drawn by normal widgets. Except from selection which would probably benefit from it, I don’t see any other use from this multi-layer system. The lines can be drawn by the cells themselves, right?
FWIW, I’m a heavy user of tables and trees. And so far, I’ve only wished for the following improvements:
- ever more speed
- row grouping (ie have labels between rows which don’t use the same renderer as cells in the other row and can potentially span multiple columns)
- single click checkbox fields toggle (ie without first double clicking on the cell)
- better autosizing than the current ResizeColumnModel (based on data width).
The demo does even load for me, using Linux Firefox 3.0.5
Sorry, meant “doesn’t”
Pingback: qooxdoo » News » The week in qooxdoo (2009-01-23)
Optimizing (perceived) scroll performance is very critical for us. Just yesterday I’ve implemented cell prefetching. This means I have an idle process, which increases the size of the layers beyond the visible window. If the user now scrolls within the prefetched data window, scrolling is instantaneous. This still needs a lot of tweaking but the basics are already in place.
Regarding your concern of the multi layer approach: I think this is one of the major benefits of the new system. It allows us to easily write very specific layers and to customize the rendered output. Right now everything is rendered by the cell renderer and combined into one single HTML string. This makes it hard to change simple things like grid lines. Just to make one point clear – we don’t plan to replace every cell renderer by widgets. Simple data will still be rendered by a simple cell renderer but now we have the option to use widgets as well. One scenario is to render check box cells using qooxdoo’s CheckBox widget and all other cells using fast HTML based cell renderer.
The URL to the demo changed yesterday. Maybe you just tested it in the wrong moment. For me the demo works in all of the browsers I have (Opera, Safari, Firefox 2/3).
Fabian, I do not think that scroll performance is mainly related to the row cache. Because after some scrolling this is mainly filled – even without prefetching. The thing is that scrolling is still quite slow. The algos which handles the moves/updates are IMHO the most critical things. This was already the case in the old Table classes and previouls in the ListView.
Gaëtan, I am also not sure about the multi-layer idea. It might be a good choice for all kind of overlay things like editable etc. But I have doubts if they are a good idea for grid lines etc. Sometimes, in quite complex scenarios, for example a virtual tree and list view with some detail infos under each item, it might be the case that the grid just renders the top-level grid (for the top-level items), but what’s about the other ones, maybe they have a different style inner vs. outer. But these are all questions we maybe could not answer today. Finally, if the idea afterwards works quite well and has a cleaner architecture than before it is still leaps better than the old version.
@Sebastin
Of cause you are right, even with a row cache and prefetching, the algorithms to update/move the table pane is absolutely critical. This is a top priority especially for the common case of pure HTML cell renderer but don’t mix up the row cache of the current table with the the new prefetching technique. The row cache stored the generated HTML but upon scrolling all rows had to be combined into one HTML string and applied to the the table pane using innerHTML. In practice setting the innerHTML takes the most time and does not benefit from the row cache. In contrast to this the new prefetching increases the size of the scroll pane beyond the size actually needed by the scroller. If the user starts to scroll, only the scrollTop/scrollLeft of the pane has to be adjusted, if the scrolled area is already prefetched.
Pingback: qooxdoo » News » Data Binding Controllers
Working now
Pingback: Ajaxian » Big qooxdoo Update: Live Debugging, Sizzle, Data-Binding
Pingback: Ajaxian » Qooxdoo Inspector and 0.8.2 Release
Pingback: Qooxdoo Inspector and 0.8.2 Release | Guilda Blog
Pingback: qooxdoo » News » qooxdoo 0.8.2 released