wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Vaynberg <igor.vaynb...@gmail.com>
Subject Re: Adding a large amount of MarkupContainers into the ListView or RepeatingView
Date Tue, 26 Mar 2013 20:48:05 GMT
On Tue, Mar 26, 2013 at 1:31 PM, Marco Springer <marco@glitchbox.nl> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message