Planning infrastructure for virtual widgets

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Planning infrastructure for virtual widgets

Fabian Jakobs
Administrator
Hi,

I want to announce that we'll shortly start work on an infrastructure
for virtual widgets (also known as table reloaded). Refer to my blog
post for details
<http://news.qooxdoo.org/infrastructure-for-virtual-widgets-call-for-ideas>.
Before we start we would like to gather feedback from the community
(that's all of you). We have a set up a wiki page, which right now
contains a list of uses cases for the table and a collection of possible
features <http://qooxdoo.org/documentation/general/virtualwidgets>. This
is still brainstorming mode. Just add your ideas to the wiki page or
post them here.

Best Fabian

--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Petr Kobalíček
This is very interesting topic for me (maybe because I still fell that
qooxdoo is slow). But I have another idea. Isn't it possible to
experiment with <canvas> based rendering ?

I think that javascript is fast enough for internet applications so
most time spent is not in JS but in DOM manipulation and rendering
pages. If there will be possibility to virtually paint for example
list box items then qooxdoo application will contain fewer DOM
elements and browser will render pages faster (and will be faster
because DOM structure will not be polluted by DIVS for nothing).
Canvas rendering is ultra fast compared to X thousands of DIVs
hierarchy.

I'm also voting to decrease of needed DIVs in qooxdoo application, but
I think that this is probably impossible :(

So, personally, instead of new features I think that qooxdoo needs performance.

Cheers
Petr

2009/1/14 Fabian Jakobs <[hidden email]>:

> Hi,
>
> I want to announce that we'll shortly start work on an infrastructure
> for virtual widgets (also known as table reloaded). Refer to my blog
> post for details
> <http://news.qooxdoo.org/infrastructure-for-virtual-widgets-call-for-ideas>.
> Before we start we would like to gather feedback from the community
> (that's all of you). We have a set up a wiki page, which right now
> contains a list of uses cases for the table and a collection of possible
> features <http://qooxdoo.org/documentation/general/virtualwidgets>. This
> is still brainstorming mode. Just add your ideas to the wiki page or
> post them here.
>
> Best Fabian
>
> --
> Fabian Jakobs
> JavaScript Framework Developer
>
> 1&1 Internet AG
> Brauerstraße 48
> 76135 Karlsruhe
>
> Amtsgericht Montabaur HRB 6484
>
> Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
> Aufsichtsratsvorsitzender: Michael Scheeren
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

redalastor
What I am wondering is if it would be possible to improve speed by
pre-rendering in html widgets at compile time. Obviously, some things
cannot be known before runtime but I'd guess that lots of things could
be pre-computed. It might require something like python-spidermonkey
(http://code.google.com/p/python-spidermonkey/) to execute Javascript
code inside a python script. And maybe we could add meta-data about
things we guarantee will never change (as in this window will never be
re-dimensioned).

I'm not sure it would be possible but if so, it would give qooxdoo one
more edge compared to the other frameworks that do not have a
toolchain to make this possible.

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Sebastian Werner
The issue is that the main performance issue is the update process.  
All other things could be easily cached/pregenerated etc. but this do  
not help when we do not have a more efficient way to update the thing  
fast.

You may note that during the scroll process the pane may be refereshed  
dozend times a second.

Otherwise an idea, but maybe not with large benefits... sorry :)

Cheers,
Sebastian



Am 25.01.2009 um 21:39 schrieb Dan:

> What I am wondering is if it would be possible to improve speed by
> pre-rendering in html widgets at compile time. Obviously, some things
> cannot be known before runtime but I'd guess that lots of things could
> be pre-computed. It might require something like python-spidermonkey
> (http://code.google.com/p/python-spidermonkey/) to execute Javascript
> code inside a python script. And maybe we could add meta-data about
> things we guarantee will never change (as in this window will never be
> re-dimensioned).
>
> I'm not sure it would be possible but if so, it would give qooxdoo one
> more edge compared to the other frameworks that do not have a
> toolchain to make this possible.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Fabian Jakobs
Administrator
In reply to this post by Petr Kobalíček
Hi Petr,

> This is very interesting topic for me (maybe because I still fell that
> qooxdoo is slow). But I have another idea. Isn't it possible to
> experiment with <canvas> based rendering ?
>
> I think that javascript is fast enough for internet applications so
> most time spent is not in JS but in DOM manipulation and rendering
> pages. If there will be possibility to virtually paint for example
> list box items then qooxdoo application will contain fewer DOM
> elements and browser will render pages faster (and will be faster
> because DOM structure will not be polluted by DIVS for nothing).
> Canvas rendering is ultra fast compared to X thousands of DIVs
> hierarchy.
>  
Canvas is interesting but even IE8 will not support it. There are ways
to emulate canvas on IE but this will result in even slower rendering. I
think we have to keep using HTML based rendering for the near future.
> I'm also voting to decrease of needed DIVs in qooxdoo application, but
> I think that this is probably impossible :(
>  
I can think of a few situation where we could svae a few DIVs but in
general reducing the umber of DIVs means also a reduction of features.
> So, personally, instead of new features I think that qooxdoo needs performance.
>  
I see this whole virtual widget topic as a way to increase qooxdoo's
performance. There are plenty of use cases where similar widgets are
arranged in a grid or list, which can benefit from virtual rendering.
Take the messenger application as example. You can use a list to create
the contacts view. This will be fast for few contacts but if the contact
list becomes larger the startup performance suffers. With virtual
rendering only widgets for the visible contacts are needed and startup
time becomes independent of the number of contacts.

Best Fabian

--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Petr Kobalíček
Hi Fabian,

thanks for response. I know that compatibility for IE is important,
but many of us are using qooxdoo for admin interfaces or intranet
applications where this incompatibility isn't too much problem (we can
say, use FF, Opera, Chrome, ...).

Virtual widgets can improve performance, but on the other side they
can flicker much more like nonvirtual ones. For example look at tree
virtual, in my machine (Turion 1.6GHz) I can scroll, but it's too much
slow.

BTW: How is your idea to decrease number of DIVs ? Is there
comparision how DIVs are using qooxdoo 0.8 application compared to
0.7.3?

Cheers
- Petr

2009/1/26 Fabian Jakobs <[hidden email]>:

> Hi Petr,
>> This is very interesting topic for me (maybe because I still fell that
>> qooxdoo is slow). But I have another idea. Isn't it possible to
>> experiment with <canvas> based rendering ?
>>
>> I think that javascript is fast enough for internet applications so
>> most time spent is not in JS but in DOM manipulation and rendering
>> pages. If there will be possibility to virtually paint for example
>> list box items then qooxdoo application will contain fewer DOM
>> elements and browser will render pages faster (and will be faster
>> because DOM structure will not be polluted by DIVS for nothing).
>> Canvas rendering is ultra fast compared to X thousands of DIVs
>> hierarchy.
>>
> Canvas is interesting but even IE8 will not support it. There are ways
> to emulate canvas on IE but this will result in even slower rendering. I
> think we have to keep using HTML based rendering for the near future.
>> I'm also voting to decrease of needed DIVs in qooxdoo application, but
>> I think that this is probably impossible :(
>>
> I can think of a few situation where we could svae a few DIVs but in
> general reducing the umber of DIVs means also a reduction of features.
>> So, personally, instead of new features I think that qooxdoo needs performance.
>>
> I see this whole virtual widget topic as a way to increase qooxdoo's
> performance. There are plenty of use cases where similar widgets are
> arranged in a grid or list, which can benefit from virtual rendering.
> Take the messenger application as example. You can use a list to create
> the contacts view. This will be fast for few contacts but if the contact
> list becomes larger the startup performance suffers. With virtual
> rendering only widgets for the visible contacts are needed and startup
> time becomes independent of the number of contacts.
>
> Best Fabian
>
> --
> Fabian Jakobs
> JavaScript Framework Developer
>
> 1&1 Internet AG
> Brauerstraße 48
> 76135 Karlsruhe
>
> Amtsgericht Montabaur HRB 6484
>
> Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
> Aufsichtsratsvorsitzender: Michael Scheeren
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Andy Fuchs
Hm - I don't suffer from performance problems here, and would vote against
'hacking' into qooxdoo, just to save some cycles.

You may be right, that Canvas or IE might not be that important, but the
nice thing about qooxdoo is, that it works under most circumstances properly
and as expected.

Please don't get me wrong: dropping IE would not be a problem for me, but
then where do you want to draw the line?
- Just dropping IE?
- Or maybe also dropping Opera?
- I don't care about Windows OS - so drop that too?
- Dropping multi-colum lists?
- Dropping animation?

I hope you understand what I mean:

 3 people - 3 opinions - 3 favorites

So rather than dropping features, I'd go and buy a faster machine :-)

best

andy



On 26.01.09 14:08, "Petr Kobalíček" <[hidden email]> wrote:

> BTW: How is your idea to decrease number of DIVs ? Is there
> comparision how DIVs are using qooxdoo 0.8 application compared to
> 0.7.3?




------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Petr Kobalíček
Hi Andy,

I'm not talking about dropping IE, I'm talking about different and
experiment infrastructure for building widgets in way that is not too
much used in web development.

For example (I know that it's complicated) some virtual widgets can
use canvas instead of dom if canvas is present. Qooxdoo has good
theming mechanism and I think that this is possible to do.

BTW: Is there any toolkit that uses <canvas> instead of DOM ?

Cheers
Petr

2009/1/26 Andy Fuchs <[hidden email]>:

> Hm - I don't suffer from performance problems here, and would vote against
> 'hacking' into qooxdoo, just to save some cycles.
>
> You may be right, that Canvas or IE might not be that important, but the
> nice thing about qooxdoo is, that it works under most circumstances properly
> and as expected.
>
> Please don't get me wrong: dropping IE would not be a problem for me, but
> then where do you want to draw the line?
> - Just dropping IE?
> - Or maybe also dropping Opera?
> - I don't care about Windows OS - so drop that too?
> - Dropping multi-colum lists?
> - Dropping animation?
>
> I hope you understand what I mean:
>
>  3 people - 3 opinions - 3 favorites
>
> So rather than dropping features, I'd go and buy a faster machine :-)
>
> best
>
> andy
>
>
>
> On 26.01.09 14:08, "Petr Kobalíček" <[hidden email]> wrote:
>
>> BTW: How is your idea to decrease number of DIVs ? Is there
>> comparision how DIVs are using qooxdoo 0.8 application compared to
>> 0.7.3?
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Jonathan Weiß-2
Hello Petr,


do you know Lively Kernel? It renders widgets completly in SVG. http://research.sun.com/projects/lively/

That is the one toolkit I am aware of that does not use DOM.


Regards,
Jonathan

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Helder Magalhães


Jonathan Weiß wrote:
>
> do you know Lively Kernel? It renders widgets completly in SVG.
> http://research.sun.com/projects/lively/
>

There are other similar projects, and I would surely like to see something
towards this direction (possibly through a contribution). Having core
classes reimplemented using SVG and therefore allowing the use of complex
widgets in SVG would be a great add-on to qooxdoo. I have been wondering if
this is at all possible and didn't propose this to the mailing list yet due
to lack of time... 2D graphics support is already included in few frameworks
such as qooxdoo - that's one item - and an interesting challenge would be to
render the widgets themselves using the 2D graphics - that's a totally
different item, though. I might return to this whenever I have more spare
time, but if someone feels like this would be interesting, please reply to
this thread or create a new one. :-)



Jonathan Weiß wrote:
>
> That is the one toolkit I am aware of that does not use DOM.
>

It does use the DOM, but the SVG DOM instead (and not the HTML one). ;-)


Cheers,

 Helder Magalhães
--
View this message in context: http://www.nabble.com/Planning-infrastructure-for-virtual-widgets-tp21456240p21687202.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Fabian Jakobs
Administrator
In reply to this post by Petr Kobalíček
Hi Petr,

> Hi Fabian,
>
> thanks for response. I know that compatibility for IE is important,
> but many of us are using qooxdoo for admin interfaces or intranet
> applications where this incompatibility isn't too much problem (we can
> say, use FF, Opera, Chrome, ...).
>
> Virtual widgets can improve performance, but on the other side they
> can flicker much more like nonvirtual ones. For example look at tree
> virtual, in my machine (Turion 1.6GHz) I can scroll, but it's too much
> slow.
>  
That's right. With virtual widgets we trade slower scrolling performance
for a better memory footprint and a faster startup time. Whether this is
sensible depends on your use cases. We don't plan to drop the non
virtual version of those widgets so everyone can choose, the best
compromise.
> BTW: How is your idea to decrease number of DIVs ?
Right now all widgets have at least two DIVs - The container element and
the content element. Optional we have a third element, which contains
the decorations. The purpose of the content element is to render the
padding in a box model independent way and to be able to update the
decoration independent of the contents. Sometimes we have widgets, which
are only used as container for layouts. In these cases we could use a
much simpler widget, which only uses one DIV element and does not
support decorators and paddings. This is on my list but has currently a
low priority. I someone wants to experiment with this I'd be happy to help.

>  Is there
> comparision how DIVs are using qooxdoo 0.8 application compared to
> 0.7.3?
>
>  
If you only look at single widgets the number of elements increased from
1-2 to 2-3. On the other hand we were able so safe whole widgets due to
the more flexible layout functionality. There are complex widgets, which
used to use nested box layouts but now use one single GridLayout. In
general I would say we have a bit more elements but 30% more as the
numbers for single widgets suggest.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG
Brauerstraße 48
76135 Karlsruhe

Amtsgericht Montabaur HRB 6484

Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: Planning infrastructure for virtual widgets

Petr Kobalíček
Hi Fabian,

thanks for detailed response :-)

Generaly I like virtual widgets and I'm looking forward to have more
ones (lists and combo popups are welcome:) ).

Cheers
Petr

2009/1/27 Fabian Jakobs <[hidden email]>:

> Hi Petr,
>> Hi Fabian,
>>
>> thanks for response. I know that compatibility for IE is important,
>> but many of us are using qooxdoo for admin interfaces or intranet
>> applications where this incompatibility isn't too much problem (we can
>> say, use FF, Opera, Chrome, ...).
>>
>> Virtual widgets can improve performance, but on the other side they
>> can flicker much more like nonvirtual ones. For example look at tree
>> virtual, in my machine (Turion 1.6GHz) I can scroll, but it's too much
>> slow.
>>
> That's right. With virtual widgets we trade slower scrolling performance
> for a better memory footprint and a faster startup time. Whether this is
> sensible depends on your use cases. We don't plan to drop the non
> virtual version of those widgets so everyone can choose, the best
> compromise.
>> BTW: How is your idea to decrease number of DIVs ?
> Right now all widgets have at least two DIVs - The container element and
> the content element. Optional we have a third element, which contains
> the decorations. The purpose of the content element is to render the
> padding in a box model independent way and to be able to update the
> decoration independent of the contents. Sometimes we have widgets, which
> are only used as container for layouts. In these cases we could use a
> much simpler widget, which only uses one DIV element and does not
> support decorators and paddings. This is on my list but has currently a
> low priority. I someone wants to experiment with this I'd be happy to help.
>
>>  Is there
>> comparision how DIVs are using qooxdoo 0.8 application compared to
>> 0.7.3?
>>
>>
> If you only look at single widgets the number of elements increased from
> 1-2 to 2-3. On the other hand we were able so safe whole widgets due to
> the more flexible layout functionality. There are complex widgets, which
> used to use nested box layouts but now use one single GridLayout. In
> general I would say we have a bit more elements but 30% more as the
> numbers for single widgets suggest.
>
> Best Fabian
>
>
> --
> Fabian Jakobs
> JavaScript Framework Developer
>
> 1&1 Internet AG
> Brauerstraße 48
> 76135 Karlsruhe
>
> Amtsgericht Montabaur HRB 6484
>
> Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Oliver Mauss, Achim Weiss
> Aufsichtsratsvorsitzender: Michael Scheeren
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> qooxdoo-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel