Uli Becker wrote:

> unfortunately the links either to the demo and the sources are down.

Apologies, I moved to a Linux host last week, and it is case sensitive. Now fixed.

--

Matthew Jones

Mark,

> - Load data into an efficient in-memory construct client-side
> - Fill display with X panels
> - Load first X items into these panels
> - Subsequent page-down / page-up commands will reload X new items into the X panels

Sorry, I didnt' read your post thoroughly. Scrolling works fine of course because the empty panels are already there.Having said that: your approach works great.

Thanks Uli

Matthew,

<<
It depends on how fancy you want to be. I originally just used a simple scroll bar, but then I got into a custom version of TListBox which handles any form you want as child.
>>

I checked that and found out that

a) creating 120 TForms on a scrollbox takes 2200 ms
b) creating 120 TBasicPanels on a scrollbox take 360 ms

Though creating a kind of template form is very comfortable it doesn't make sense if you need to create a big number of items.

Uli

What we really need is an analogy to Delphi’s old “frame”

A lightweight TPanel based entity that you design in the IDE with no need to create a component

> A lightweight TPanel based entity that you design in the IDE with no need to create a component

Two more benchmarks:

1. Creating 120 TBasicPanel's with one TImage- und 2 TLabel-components
take 1400 ms including populating the components

2. Using a custom component derived from TBasicPanel with the same
elements take about 800 ms for 120 items including assigning properties.
(See screenshot).

So using a custom component seems to be the best solution as of
performance for the moment.

Uli

Mark Brooks wrote:

> What we really need is an analogy to Delphi’s old “frame”

No, what we /really/ need is TForms that are as fast as a TPanel. But a TPanel is probably going to slow down a lot once you put on the labels and other controls that make them useful. The TFrame was good, but became a nightmare when nested.

--

Matthew Jones

Uli Becker wrote:

> So using a custom component seems to be the best solution as of performance for the moment.

Useful - thank you. Now we just need the drag and drop convenience of the TForm (or TFrame). I guess though that the key is the abstraction that the TForm and TPanel provides is where the time cost goes. Get down to the metal and you don't need the general parsing code etc, you just make what you need explicitly. As with all these things, the key is to not optimise until it is an issue.

--

Matthew Jones

"Matthew Jones" wrote:

>>No, what we /really/ need is TForms that are as fast as a TPanel. But a TPanel is probably going to slow down a lot >>once you put on the labels and other controls that make them useful. The TFrame was good, but became a >>nightmare when nested.

Well that's kinda the same thing then!

Trust in Tim to get the implementation right.

Uli,

<< Two more benchmarks: >>

I suspect that the majority of the time is being spent in the JSON parsing and instantiation of the form.

IOW, even if I were to allow for design-time content "frames" in the IDE, they would still exhibit around the same level of instantiation overhead (dependent upon their content).

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> I suspect that the majority of the time is being spent in the JSON parsing and instantiation of the form.

Sorry, I should have mentioned that.
No, the panels (either custom components or not) are populated from a
dataset (localhost in this case). The procedure has been called from a
button click event.

Uli