On Tue, Mar 26, 2013 at 2:00 PM, Marco Springer <[email protected]> wrote:
>
> 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 :)
thats some optimistically farsighted planning :)
>>
>> -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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
