Poor resizeStack performance when lots of text in scrolling field

[mattyj2001]

Howdy!

I have a stack with a simple scrolling text field in it that could potentially have a huge amount of text in it (50,000 words or more.) Think like perhaps a text/document editor that someone is using to write a book. (desktop app, Mac target for now)

When lots of text is in that field, resizing the stack is slow and choppy. The more text, the more choppy. I'm on a brand new M1 MacBook Pro so I don't think it's laptop resources.

I've tried using geometry as well as simply this in onResizeStack (generic test app with just the one field in it):

Code: Select all

set the rect of field "Field" of card id 1002 of me to the rect of card id 1002 of me

If you paste that much text in the field using the LC IDE, resizing the field itself behaves the same way so I'm thinking it's a field limitation but wanted to check with the experts in case there was some voodoo I could perform to get it to work.

The thought crossed my mind to use a data grid to masquerade as a text field but wanted other opinions before I dip into that one. I've put 20,000 items in a data grid during a test and resizing the stack is barely affected, presumably due to how it only renders what's in view.

Thanks!

[dunbarx]

Hi.

I made a new stack with a field on it. I placed 50,000 random words into that field. I then resized the card, and also resized the field to the rect of the card. There was a half second delay in that process. Much the same delay was noticed if only 1000 words was loaded. But if only 100 words were loaded, the change took place instantly. There does seem to be a lag, and locking the screen does not seem to help.

Craig

[mattyj2001]

Thanks for trying that, glad it's not just me.

Weirdly/interestingly(?) it continues to do the same thing if you have the field disabled and/or hidden.

[mattyj2001]

I've been experimenting with this more and have found that using a data grid helps, depending on the grid.

In table mode (single column) it works 100%. No lag whatsoever when resizing/moving with geometry.

However, a form mode data grid looks like it will work at first, but the more you scroll up and down the worse the resize/move lag/choppiness gets until it's about the same as a text field.

For fun I put all that text into other unreasonable types of fields and the Mac native single line field also had no trouble with resizing with that much data in it.

For now I might be able to get by with using a data grid masquerading as a text field.

Bug report: https://quality.livecode.com/show_bug.cgi?id=23539

[dunbarx]

I am not sure this is a bug, but rather just the LC engine working time to do a task.

I upped the number of words in the field to 500,000, and it took 4.5 seconds to resize. That the length of the text of the field has a lot to do with the time it takes to resize that field seems not outlandish to me. Apparently it does take time, and with a modest amount of text we just never notice it.

So is this a process that you intend to use regularly, and are worried that the user will bark? Perhaps there is another way to do it.

Craig

[FourthWorld]

For now I might be able to get by with using a data grid masquerading as a text field.

Bug report: https://quality.livecode.com/show_bug.cgi?id=23539

A DataGrid is a grouped collection of field objects.

Thank you for submitting the bug report, and including the example stack.

Looking it over I get a slightly better experience if I remove the Geometry Manager stuff and just use this in the card script:

Code: Select all

on resizeStack
   set the rect of fld 1 to the rect of this cd
end resizeStack

Even then it's less snappy than I'd expect. The text isn't that long, only 7,74,837 chars, so while I would expect a measurable delay to recalculate all the soft-wraps, I would expect it to be less visibly evident.

I may be misremembering, but I could have sworn I did a similar soft-wrap stress test several years ago with a snappier result.

I'm keen to see what the team discovers there.

[mattyj2001]

So is this a process that you intend to use regularly, and are worried that the user will bark? Perhaps there is another way to do it.

Yeah, perhaps. It's up to the user. The tool I'm attempting to write is going to process steno from court reporters. Depending on what they're recording, say a deposition with multiple people talking for an entire day, it could easily generate several 10's of thousands of words.

It theoretically is a sort of specialized word processor and people are used to resizing and dragging not slowing things down, so I would expect some of my future millions of customers (one can dream, ha ha) might think it's broken if it does that.

[dunbarx]

It theoretically is a sort of specialized word processor and people are used to resizing and dragging...

I bet you can build this without the "feature" of resizing, and nobody will care. To me, such a recording gadget needs to scroll live as text is entered, zoom to a portion of the narrative based on one or more "find" tools, and present itself in a pleasing and inviting way. I cannot imagine that resizing is something that is desired, or even useful.

Why at all? To show a larger section of a certain section of text at one glance? Make the card large to begin with.

So much for my uninformed opinion.

Craig

[SparkOut]

I think a lot of users would expect to be able to resize an application, and feel it is less than professional if not possible, if not downright broken.

How does it perform if you copy the text into a variable in the resize handler and empty the field, then send a message to put the contents back in one go in (say) 500 milliseconds after resizing? You would need some flags set so that the process only triggers once to populate the variable and empty field, and cancel any pending message to refill the field until the resize is definitely completed.

[dunbarx]

Sparkout.

Good idea. Tried that. Faster, about three seconds with 500,000 words. Only a third of a second with 50,000.

But this is if done with a single stand-alone handler, run after the user resizes by hand. If the idea is to resize "live", with the field tracking the card rect, then this needs more work.

Craig

[dunbarx]

So using the "resizeStack" message:

Code: Select all

on resizeStack
   put fld 1 into temp
   set the rect of field 1  to the rect of this cd
   put temp into fld 1
end resizeStack

This is with 50K words.

Works, but the act of resizing is very jerky. The dictionary says the message is sent only after the resize action ends, but this does not seem to be the case. the jerkiness appears to be as if the message, and the resizing itself, occurs continuously.

The "mouseMove" message is not sent when the user resizes, so that is out.

Craig

[dunbarx]

The "resizeStack" handler alone works just fine with a field that contains only about 10,000 words.

Code: Select all

on resizeStack
   set the rect of field 1  to the rect of this cd
end resizeStack

Jerkiness starts after that, becoming ever more noticeable as the number of words increases. After 20K words or so, the experience will appear in a bad light.

This still does not answer my issue, which is that the "resizeStack" message seems to the sent continuously, not merely at the end of the process as the dictionary states. In fact, I like it much better this way.

Craig

[Klaus]

There is a 14 year old feature request by Trevor deVore to add a resizeStackStart and resizeStackEnd messages.
https://quality.livecode.com/show_bug.cgi?id=7310
Not even a response from the mothership yet...

[dunbarx]

Klaus.

There is a 14 year old feature request by Trevor deVore to add a resizeStackStart and resizeStackEnd messages.

This implies that the "resizeStack" message is sent continuously, not just at the end, as per the dictionary:

The resizeStack message is sent after the resizing is finished. This means that you cannot prevent a stack's size from being changed by trapping this message.

But I still am intrigued as to how this works. In the stack script of a card with a field:

Code: Select all

on resizeStack
   breakpoint
   put random(99) 
end resizeStack

Nothing happens during the resize process. The breakpoint never catches anything. BUT, if one plays around for a little bit, resizing all the while, when the mouse is released, it can be seen in the message box literally dozens, if not more, of random numbers being shown in a stream. So the resizeStack message is indeed sent repeatedly, but cannot be trapped at all.

I want to make this a new thread.

Craig

[bn]

I adapted a hack I once made for exactly this problem to illustrate a solution that is not perfect but somewhat works.

It assumes that the fixedLineHeight of the field is set to true. (could probably be coaxed to work without too)

It furthermore assumes that the text is "styled" meaning that it is not plain text in the field but text has been "bolded" / colored etc and uses the styledText to operate on. This is considerable slower than using plain text.

It takes into account that the text can be scrolled and that it would be undesirable to jump to the first line, it is trying to keep the scroll while resizing.

The stack takes the lines around the current scroll to display and the rest of the lines of the field are set to empty.

To test this in the attached stack I used the script of "RevDataGridLibraryBehaviorsDataGridButtonBehavior" which has about 11500 lines and 45000 words.

If you want to use that script open it from the ProjectBrowser while "Show IDE Stacks" is true (in menu View)

There is a considerable lag before resizing starts and after resizing finishes but actual resizing is not too bad. Please note that after resizing a selection in the field is reselected. That also goes if there is a blinking cursor in line 1 because of tabbing into the field and then scrolling down to test.

Kind regards
Bernd