|Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder 2 Preview » View Thread|
|Messages 1 to 10 of 16 total|
|Label Format Performance Problem|
|Fri, Jun 5 2015 9:09 AM||Permanent Link|
Many of my applications need to display lists of things e.g. documents, comments, discussions, versions, users. In order to achieve this in EWB2 I thought that I would create a TScrollPanel and add child TLabels. For each label I would set up Layout, Padding etc. This works ok and seems quite performant, provided that you use the TScrollPanel's BeginUpdate and EndUpdate.
However, if you also set Format.Wrap := True for each child label, then everything slows down by several orders of magnitude. I can even kill the browser. My sample code is shown below:
procedure TfrmMain.btnAddClick(Sender: TObject);
for I := 1 to 200 do
with TLabel.Create(pnlScroll) do
with Padding do
Top := 4;
Left := 8;
Bottom := 4;
Right := 8;
with Border.Bottom do
Visible := True;
Color := clGray;
with Layout do
Position := lpTopLeft;
Stretch := lsRight;
Consumption := lcBottom;
//Format.Wrap := True;
Caption := 'This is label number ' + IntToStr(pnlScroll.ControlCount);
I have commented out the line that causes the problem. Wrapping is required in order to handle list items whose names (i.e. label captions) are too long to fit. This may even be something to do with the previous reported error re: scrolling / layouts?
|Fri, Jun 5 2015 9:28 AM||Permanent Link|
I can confirm that, but haven't reported it yet by mail due to Tim's wish to wait until the final release is out.
|Fri, Jun 5 2015 9:43 AM||Permanent Link|
Uli Becker wrote:
> but haven't reported it yet
I think that's fair - it's an issue, but not a show stopper like the
sizing. Tim needs to get it shipped, get some buzz going, and can fix
things in the weeks after. We need the buzz too, to make it a viable
|Fri, Jun 5 2015 9:54 AM||Permanent Link|
I agree with you both, however it's difficult to know at this stage what to report and what not to. What's key to one individual may not be to another. This is certainly vital to me and anybody building responsive apps.
Furthermore, what may appear "not currently relevant" at this time, could actually be part of a much larger underlying problem. Clearly wrapping and layouts don't sit well together, I think.
Either way, this thing is panning out to be something really spectacular and we are the lucky early adopters.
|Fri, Jun 5 2015 9:57 AM||Permanent Link|
Matthew Jones wrote:
> but not a show stopper
FWIW, EWB is not alone in having these issues. Xamarin Forms had some
significant issues in its early releases, and overcoming these sorts of
automatic sizing issues is always a pain. Lots of power though, and I'm
looking forward to using it soon.
|Fri, Jun 5 2015 10:52 AM||Permanent Link|
> What's key to one individual may not be to another. This is certainly vital to me and anybody building responsive apps.
> Furthermore, what may appear "not currently relevant" at this time, could actually be part of a much larger underlying problem. Clearly wrapping and layouts don't sit well together, I think.
You are right - probably it will be the best to report the issue.
> Either way, this thing is panning out to be something really spectacular and we are the lucky early adopters.
Absolutely. +1 from me.
|Fri, Jun 5 2015 1:58 PM||Permanent Link|
Tim Young [Elevate Software]
Elevate Software, Inc.
<< However, if you also set Format.Wrap := True for each child label, then
everything slows down by several orders of magnitude. >>
The issue is that EWB has to measure the strings in order to know how big
they are when wrapped, and measuring strings is horribly slow in browsers.
EWB has "live" layout management, where dimensions are available immediately
to both the UI layer and the developer, so it has to constantly measure the
strings, and this is where the problem lies. EWB goes to great lengths to
minimize the effects of this by caching measurements, etc., but it can only
do so much. It's probably going to need to be re-architected, but it's not
something I'm really keen on trying to do right now.
If you want to see what is going on, check out the TContentSizer class in
the WebUI unit.
|Fri, Jun 5 2015 3:13 PM||Permanent Link|
"Tim Young [Elevate Software]" wrote:
>>The issue is that EWB has to measure the strings in order to know how big
>>they are when wrapped, and measuring strings is horribly slow in browsers.
Understood Tim. I will find another way. Cheers.
|Fri, Jun 5 2015 6:45 PM||Permanent Link|
> I will find another way.
Of course I don't know your needs, but a possible approach could be to
use a kind of "spoiler" for larger text in scrollboxes.
I did that in the new version of Cinedisk, that has a new feature "TV
Series" and is online now.
When you choose a series and click on a season's poster, the episodes
are displayed. In this form all "Overview" labels are created with
format.wrap = false. When you click on the matching treeview icon the
label's caption is changed and format.wrap set = true. See the attached
Just an idea.
|Sat, Jun 6 2015 11:48 AM||Permanent Link|
On 6/5/2015 3:13 PM, Mark Brooks wrote:
> Understood Tim. I will find another way. Cheers.
Have not looked at scrollpanel but i wonder how difficult would it be do
a virtual scrollpanel where you fill actual data only as it becomes
visible when scrolled (or at least make wrap it only as it becomes visible)
|Page 1 of 2||Next Page »|
|Jump to Page: 1 2|