On Tuesday 26 March 2013 13:48:05 Igor Vaynberg wrote:
> On Tue, Mar 26, 2013 at 1:31 PM, Marco Springer <[email protected]> wrote:
> > Actually, the performance problem was in the first row, well actually the
> > header that was rendering all days in a week/month/year.
> >
> > Each data row itself has a lot less items.
> > Each row has items that are absolutely positioned within the relatively
> > positioned row. Each item can span over multiple days/week/months or even
> > years, depending on the task duration.
> >
> > Doing this instead of rendering divs for each day saves a lot of
> > calculation on the server side and a whole lot less html on the client
> > side.
> > And this creates other nifty possibilities like making the item divs
> > resizable and draggable in that row with bound ajax calls to those
> > actions.
> > For showing a grid I've done some background images that match the zoom
> > level, since each day is static in width.
> >
> > I've thought about lazy loading the rows that where outside of the
> > scrollable view, since I indeed have a scrollable view.
> > But that's something for the future.
> >
> > Rendering the 287 years
>
> pretty sure gantt charts didnt exist 287 years ago... :)
who talks about the past! the future baby! 26 Feb 2013 - 26 Feb 2300 :)
>
> -igor
>
> > , e.g. 104k~ ish days, did render eventually and the server
> > and browser didn't choke, but the div with was about 5M px width wide, so
> > that was nonsense :P
> >
> > On Wednesday 27 March 2013 05:25:40 Bernard wrote:
> >> Hi,
> >>
> >> AFAIK the solutions for large numbers of cells in GUI frameworks are:
> >>
> >> 1) Do not render cells that are not in the scrollable view
> >> 2) Create components only per once row or column and provide cell
> >> renderers. See javax.swing.table.TableCellRenderer
> >>
> >> With these approaches there is basically no limit to the amount of
> >> data that can be displayed on the screen.
> >>
> >> The current architecture seems to be here that the entire view is
> >> "rendered" on the server irrespective of how much of it is displayed
> >> in the client. This rules out 1)
> >>
> >> Still the current architecture allows to exploit 2) which would solve
> >> your performance problem if applicable to your use case. But that is
> >> theory until someone creates TableCellRenderer for Wicket.
> >>
> >> Kind Regards,
> >>
> >> Bernard
> >>
> >> On Tue, 26 Mar 2013 16:07:17 +0100, you wrote:
> >> >Hi,
> >> >
> >> >Lets say I have about ~100.000 of MarkupContainer objects that I want to
> >> >put into a ListView or RepeatingView.
> >> >This works fine functional wise... It's rather slow though.
> >> >
> >> >It boils down to:
> >> >MarkupContainer:
> >> >1309 private Component put(final Component child)
> >> >1310 {
> >> >1311 int index = children_indexOf(child);
> >> >1312 if (index == -1)
> >> >1313 {
> >> >1314 children_add(child);
> >> >1315 return null;
> >> >1316 }
> >> >1317 else
> >> >1318 {
> >> >1319 return children_set(index, child);
> >> >1320 }
> >> >1321 }
> >> >
> >> >and the call to "children_indexOf(child)" where it loops over all it's
> >> >existing children and compares the id's until a match is found.
> >> >With an increasing amount of children this can get rather slow...
> >> >
> >> >I though off overruling some functionality in the MarkupContainer class
> >> >since I'm sure that for this list of items the children will be unique
> >> >in
> >> >their id and don't need that lookup, and overruling the "put" or
> >> >"children_indexOf" function would give me enough power to skip that
> >> >performance impacting part. But most functions have private access,
> >> >leaving me nothing to control the adding of child components to a
> >> >MarkupContainer.
> >> >
> >> >Does anyone else have experience with adding rather large quantities to
> >> >something like the ListView and/or RepeatingView?
> >> >Or is there another way of rendering this large amount of containers?
> >> >
> >> >Thanks in advance.
> >> >
> >> >Kind regards,
> >> >Marco
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [email protected]
> >> For additional commands, e-mail: [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
