canvas and the table widget

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

canvas and the table widget

oetiker
As explained the other day I am working on a canvas cell renderer,
it has been working pretty well for some time now, except that the
contents of the canvas cells misteriously dissapeared when
scrolling through the table. I have no investigated the problem and
found the reason (and a solution).

The table.pane.Pane creates the content of the table pane by
joingin html fragments representing the individual rows of the
table and in the end inserting the result into the body of the
table.

The problem with the canvas element is that it can only have
rendered content while it is a DOM node, this means that if the
table pane recreates the table content by concatinating cached HTML
fragments and then reinserting them into the DOM, the content of
the rendered canvas cells will be lost.

short of rewriting the table widget I have found a workaround for
the problem. My cell renderer now contains a cache map storing the
canvas elements once they are rendered. Whenever the renderer is
triggered, it lookes up the elements in the cache and replaces the
freshly created canvas node with the already rendered aequivalent.

is the table widget realy faster by doing string manipulation
instead of jugging dom nodes ?

cheers
tobi

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: canvas and the table widget

Helder Magalhães

Hi everyone,


Tobias Oetiker-3 wrote:
>
> is the table widget realy faster by doing string manipulation
> instead of jugging dom nodes ?
>

Good question. As browsers are getting faster and more efficient (I recall
setting "innerHTML" was almost a hack which helped old browsers), I'm not
sure if it applies anymore. Of couse that would mean a tremendous amount of
work...

In the meantime, that would probably help fixing
http://bugzilla.qooxdoo.org/show_bug.cgi?id=2521 issue 2521  and maybe
more...


Cheers,
 Helder




--
View this message in context: http://old.nabble.com/canvas-and-the-table-widget-tp26535655p26543185.html
Sent from the qooxdoo-devel mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: canvas and the table widget

oetiker
Hi Helder,

Today Helder Magalhães wrote:

>
> Hi everyone,
>
>
> Tobias Oetiker-3 wrote:
> >
> > is the table widget realy faster by doing string manipulation
> > instead of jugging dom nodes ?
> >
>
> Good question. As browsers are getting faster and more efficient (I recall
> setting "innerHTML" was almost a hack which helped old browsers), I'm not
> sure if it applies anymore. Of couse that would mean a tremendous amount of
> work...
>
> In the meantime, that would probably help fixing
> http://bugzilla.qooxdoo.org/show_bug.cgi?id=2521 issue 2521  and maybe
> more...
I don't think the work would be that bad ... in the most simple
case, I would just asemble the html for a row as it is done now,
but instead of caching the html I would turn the row into a dom
object and cache this. later as the rows are asembled into a long
html string I would just add the dom nodes to the target in
question ...

in such a way the dom elements would keep all their attached stuff
... probably makeing tables faster as well as more stable in the
same turn.

obviously one could take a more radical aproach, but this would at
least solve the canvas distruction issue.

cheers
tobi

>
> Cheers,
>  Helder
>
>
>
>
>

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [hidden email] ++41 62 775 9902 / sb: -9900
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: canvas and the table widget

Derrell Lipman
In reply to this post by Helder Magalhães
2009/11/27 Helder Magalhães <[hidden email]>

Tobias Oetiker-3 wrote:
>
> is the table widget realy faster by doing string manipulation
> instead of jugging dom nodes ?
>

Good question. As browsers are getting faster and more efficient (I recall
setting "innerHTML" was almost a hack which helped old browsers)

A number of years ago, Sebastian (I think) did quite a bit of work testing various approaches to fastest rendering. DOM nodes were manipulated directly, innerHTML was set, and one or two other options were also tested. In fact, the Table cell renderers had selectable rendering and could use DOM or innerHTML or one other thing I don't recall. At the time, I recall that innerHTML was a pretty clear winner, and at some point, the other renderers were discarded from the code. It would probably be useful to resurrect that code in Table, or to find Sebastian's early testing code to ascertain whether the early findings are still valid or if there's a faster renderer for modern-day browsers.

Derrell


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: canvas and the table widget

Fabian Jakobs
Administrator
In reply to this post by oetiker
Tobias Oetiker schrieb:

> As explained the other day I am working on a canvas cell renderer,
> it has been working pretty well for some time now, except that the
> contents of the canvas cells misteriously dissapeared when
> scrolling through the table. I have no investigated the problem and
> found the reason (and a solution).
>
> The table.pane.Pane creates the content of the table pane by
> joingin html fragments representing the individual rows of the
> table and in the end inserting the result into the body of the
> table.
>
> The problem with the canvas element is that it can only have
> rendered content while it is a DOM node, this means that if the
> table pane recreates the table content by concatinating cached HTML
> fragments and then reinserting them into the DOM, the content of
> the rendered canvas cells will be lost.
>
> short of rewriting the table widget I have found a workaround for
> the problem. My cell renderer now contains a cache map storing the
> canvas elements once they are rendered. Whenever the renderer is
> triggered, it lookes up the elements in the cache and replaces the
> freshly created canvas node with the already rendered aequivalent.
>
> is the table widget realy faster by doing string manipulation
> instead of jugging dom nodes ?
>  
Yes! Especially on older browsers the difference is huge. It is the
difference between unusable and decent scrolling speed. We had
implementations for both and even on newer browser the still is a
difference.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: canvas and the table widget

Fabian Jakobs
Administrator
In reply to this post by Derrell Lipman
Derrell Lipman schrieb:

> 2009/11/27 Helder Magalhães <[hidden email]
> <mailto:[hidden email]>>
>
>
>     Tobias Oetiker-3 wrote:
>     >
>     > is the table widget realy faster by doing string manipulation
>     > instead of jugging dom nodes ?
>     >
>
>     Good question. As browsers are getting faster and more efficient
>     (I recall
>     setting "innerHTML" was almost a hack which helped old browsers)
>
>
> A number of years ago, Sebastian (I think) did quite a bit of work
> testing various approaches to fastest rendering. DOM nodes were
> manipulated directly, innerHTML was set, and one or two other options
> were also tested. In fact, the Table cell renderers had selectable
> rendering and could use DOM or innerHTML or one other thing I don't
> recall. At the time, I recall that innerHTML was a pretty clear
> winner, and at some point, the other renderers were discarded from the
> code. It would probably be useful to resurrect that code in Table, or
> to find Sebastian's early testing code to ascertain whether the early
> findings are still valid or if there's a faster renderer for
> modern-day browsers.
These tests could easily be done with the new virtual widget stuff as
they only concentrate on rendering and it is pretty easy to provide
alternative pane renderers. I don't think it makes any sense to
resurrect the DOM table code as it probably won't work.

Best Fabian


--
Fabian Jakobs
JavaScript Framework Developer

1&1 Internet AG - Web Technologies
Ernst-Frey-Straße 9 · DE-76135 Karlsruhe
Telefon: +49 721 91374-6784
[hidden email]

Amtsgericht Montabaur / HRB 6484
Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
Aufsichtsratsvorsitzender: Michael Scheeren


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel