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... :)
-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]
