Uli / Raul

Thanks very much for your ideas. I'm gonna play with this some more. I guess there will be a number of approaches, but you've given me something to think about immediately.

Appreciated
Mark

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

I don't think I've fully understood this, but how variable is the label
parent's width? Would a fixed width parent solve the resize problem? It
strikes me that the key here is that there are circular dependencies,
but if the parent panel for the labels is fixed width, then the labels
can't be changing in height repeatedly. Or did I not get this right?

Obviously it is hard to do this automatically, and I'd perhaps suggest
that the code should do nothing more than detect that it has cycled
twice and then raise some sort of exception or callback for anyone who
cares. But if fixed width parent solves it, then it is a good way
forward (the code could manually change the width, but the auto-layout
pick up the new constant).

Mark,

<< Understood Tim. I will find another way. Cheers. >>

Okay, I looked at this further over the weekend, and there is indeed a small
bug in the layout management when a label control is auto-sized, set to
wrap, and set to stretch right/left.  In such a case, the caching of the
measured heights of each label is defeated because the height is calculated
twice, and both in different ways.  The end result is that the cached
heights are never used, so the labels are being constantly re-measured.

I can now create 200 labels in the scrollable panel on the left with just a
slight pause in IE, and no pause in Chrome/FF.

I also added a throttle for the browser window resizing that helps keep
things snappier by limiting the number of resize events to one every 10ms.

A fix will be in a build 12 that I'm uploading this morning.

Tim Young
Elevate Software
www.elevatesoft.com

Matthew,

I actually fixed Mark's creation issue over the weekend, but there was
another scrollbar updating issue that I fixed separately.  The following is
an explanation of how it worked before the fix.

<< I don't think I've fully understood this, but how variable is the label
parent's width? Would a fixed width parent solve the resize problem? >>

The issue was the client rectangle resizing due to the scrollbars.  Every
time a scrollbar is updated, EWB has to:

1) Show the scrollbar in its default state.  Things have to be done this way
because the layout of the scrollbar is controlled by the control interface,
not code, and step 2) needs accurate measurements.

2) Check to see if there is enough gutter space for the buttons and thumb.

3) If yes to 2), then update as normal.  If no to 2), then "hide" the
scrollbar by making its width (vertical) or height (horizontal) 0.

It's this toggling of the scrollbar that can cause things to get slow, due
to the fact that every time this happens the parent control has to re-layout
all 200+ auto-sized, wrapped and stretched labels.  The re-layout is very
fast, but the label content measurement is very slow, and this bouncing back
and forth with steps 1) and 3) would cause any cached measurements for the
labels to become discarded.

I fixed this problem, and a recursive sizing issue related to it that could
cause lockups (also mentioned by Mark), by just getting rid of updating the
scrollbars during a resize of the parent control.  It wasn't necessary
because there were later scrolling updates that were a more appropriate
location to do this, and introduced performance and recursion issues during
steps 1) and 3).

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>I can now create 200 labels in the scrollable panel on the left with just a
>>slight pause in IE, and no pause in Chrome/FF.

Well, I have no idea what sort of "magic EWB oil" you applied to this issue, but I'm happy to report that it now runs like a dream. No discernible difference with or without wrapping for lists into the 100s. Great stuff.

I do have a problem, however, when trying to load just over 8 million items - can you help with that .............. ?

Mark,

<< Well, I have no idea what sort of "magic EWB oil" you applied to this
issue, but I'm happy to report that it now runs like a dream. No discernible
difference with or without wrapping for lists into the 100s. Great stuff. >>

Good, I'm glad that it's working well for you now.  No magic oil - just
allowing the UI layer to do what it is supposed to be doing - avoid
measuring text like it's the plague...

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com