Poor resizeStack performance when lots of text in scrolling field

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Poor resizeStack performance when lots of text in scrolling field

Post by jacque » Wed Feb 02, 2022 9:07 pm

LiveResizing is deprecated, you can't turn it off any more. Resizing is always live now. If you're using an old copy of LC the dictionary probably doesn't mention that.

The OP should be aware that fields have a text limit so at some point, long text will no longer be displayed. I hit this problem in one of my stacks last year and the only solution was to implement Trevor Devore's dataView, which is based on the dataGrid but displays text instead. https://github.com/trevordevore/levurehelper-dataview

It's a bit complicated to implement but it works. A simpler alternative would be to split the text into pages and provide forward and backward navigation. Keeping the field text smaller would automatically make resizing more responsive.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10043
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Poor resizeStack performance when lots of text in scrolling field

Post by FourthWorld » Wed Feb 02, 2022 9:27 pm

jacque wrote:
Wed Feb 02, 2022 9:07 pm
The OP should be aware that fields have a text limit so at some point, long text will no longer be displayed. I hit this problem in one of my stacks last year and the only solution was to implement Trevor Devore's dataView...
That's concerning. Do you know what the limit is, and whether a bug report has been filed for that?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10305
Joined: Wed May 06, 2009 2:28 pm

Re: Poor resizeStack performance when lots of text in scrolling field

Post by dunbarx » Wed Feb 02, 2022 9:46 pm

My old buddies, all together...

I made a field and a button on a card, with this in the button script:

Code: Select all

on mouseUp
   repeat 10000000
      put "1234567890" & return after temp
   end repeat
   put temp into fld 1
end mouseUp
That is ten million words, and 110,000,000 characters. It only took about three seconds for the repeat loop to finish, and about a minute for the field to load. I got a beachball for most of that time, but was not deterred. The reason is that I started with smaller amounts of words, and after a million or so the beach ball appeared for just a few seconds.

Anyway, LC does not seem to mind a ten million word field. Shall I push it?

The Encyclopedia Britannica has 300-odd million words.

Craig

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10305
Joined: Wed May 06, 2009 2:28 pm

Re: Poor resizeStack performance when lots of text in scrolling field

Post by dunbarx » Wed Feb 02, 2022 9:53 pm

About the above silliness.

If there is a lesson here, know that the beachBall of death may not mean that at all. It just means that my machine notices that a process seems, seems to be stuck, and it very well may not be.

Craig

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10305
Joined: Wed May 06, 2009 2:28 pm

Re: Poor resizeStack performance when lots of text in scrolling field

Post by dunbarx » Wed Feb 02, 2022 10:27 pm

It takes the message box many seconds along with a few seconds of beachBall action to even answer this query about 10 million words:

Code: Select all

 answer the number of words of fld 1
It takes the same time and shows the same beachball just saving the stack itself.

I wonder how many times I have aborted LC and did not need to.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Poor resizeStack performance when lots of text in scrolling field

Post by jacque » Wed Feb 02, 2022 10:31 pm

FourthWorld wrote:
Wed Feb 02, 2022 9:27 pm
That's concerning. Do you know what the limit is, and whether a bug report has been filed for that?
I don't remember, if I ever knew, what the limit is, but it's a lot. Trevor wrote his tool to overcome the same problem. This happened when I was doing a Bible conversion for a client. The book of Matthew fit, Psalms did not.

I don't think it's a bug, I think the old limit may still be in effect, but now that we're using unicode all the text has doubled or more in size. In my case there were additional elements besides the actual book text, like footnotes, styling, metadata, etc. There's more to a field than just the words and LC has to hold it all in RAM.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10043
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Poor resizeStack performance when lots of text in scrolling field

Post by FourthWorld » Wed Feb 02, 2022 11:08 pm

Thanks. I'm still surprised by the limit, though. I could have sworn I put the entire Gutenberg Project King James Bible into a field for stress testing back in the day.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Poor resizeStack performance when lots of text in scrolling field

Post by jacque » Thu Feb 03, 2022 1:06 am

It might be interesting to see if you could still put the whole KJV into a field.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10305
Joined: Wed May 06, 2009 2:28 pm

Re: Poor resizeStack performance when lots of text in scrolling field

Post by dunbarx » Thu Feb 03, 2022 4:15 am

The King James bible, depending on the breaks, has about 780,000 words. That would not even make the beachball appear.

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10043
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Poor resizeStack performance when lots of text in scrolling field

Post by FourthWorld » Thu Feb 03, 2022 4:34 am

jacque wrote:
Thu Feb 03, 2022 1:06 am
It might be interesting to see if you could still put the whole KJV into a field.
Yeah, well, I'm using the Linux version at the moment, so the result is even odder than any oddness you'd expect on Mac or Win.

In Ubuntu's default text editor (for comparison):
Copy from full KJV text, paste into new document: whole thing is there, renders in under 1 second.

In LC field:
Copy from KJV text, paste into field, wait about 10 seconds, and this is all that's show in the field:
}B

Okay, maybe it's an issue with LC's clipboard handling on Linux.

So I used the Inspector to import the text directly from the Gutenberg file. Seems to work well, all 4,453,945 chars rendered. Took about 8 second to render (this is on an older machine), but scrolls lightning fast.

The rendering time is unfair in this text, since of course it renders in the Inspector before rendering in the field, so it's doing double-duty.

Then I tried a resizeStack handler to set the field size. Prohibitively long, about 10 seconds to finish rendering. Ubuntu Text Editor resizes snappily in real-time.

Here's an oddity: I can scroll through the document, select some text, deselect, scroll on, repeat, etc. all the way through, very snappy. But if I use LC IDE's Edit-> Select All it doesn't render the selection color. But it does seem to copy well when selected - I can paste into Ubuntu Text Editor without issue, full text intact.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7389
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Poor resizeStack performance when lots of text in scrolling field

Post by jacque » Thu Feb 03, 2022 6:04 am

Interesting. My text was entirely html that at least doubled the amount of plain text, including tons of links and cross-references. I set the htmltext of the field. It may be that html makes a difference. On the other hand, the total size of the entire Bible's html files is under 17MB, which doesn't seem too much. All I can figure is that there's something about the rendering that hits a limit.

It sounds like plain text may not be a problem in this case. I wonder what Trevor was doing when he hit the limit. I never asked.

Edit: Another thought, the field is limited by the amount of available memory. The app was for mobile where memory is limited.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

mattyj2001
Posts: 15
Joined: Tue Apr 04, 2017 8:02 am

Re: Poor resizeStack performance when lots of text in scrolling field

Post by mattyj2001 » Thu Feb 03, 2022 8:13 am

I've also noticed that other than resizing, the field with lots of text in it performs pretty well. Scrolling, copy/paste, select, etc. seems normal.

Regarding rendering, if we're talking about actually rendering to screen, the performance degradation (on desktop) also happens when the field is hidden.

And I've also noticed if you paste the text into the inspector, the inspector itself shows the resize choppiness, too.

Post Reply