Poor resizeStack performance when lots of text in scrolling field
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Re: Poor resizeStack performance when lots of text in scrolling field
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.
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
HyperActive Software | http://www.hyperactivesw.com
-
- 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
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Poor resizeStack performance when lots of text in scrolling field
My old buddies, all together...
I made a field and a button on a card, with this in the button script:
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
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
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
Re: Poor resizeStack performance when lots of text in scrolling field
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
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
Re: Poor resizeStack performance when lots of text in scrolling field
It takes the message box many seconds along with a few seconds of beachBall action to even answer this query about 10 million words:
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
Code: Select all
answer the number of words of fld 1
I wonder how many times I have aborted LC and did not need to.
Craig
Re: Poor resizeStack performance when lots of text in scrolling field
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.FourthWorld wrote: ↑Wed Feb 02, 2022 9:27 pmThat's concerning. Do you know what the limit is, and whether a bug report has been filed for that?
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
HyperActive Software | http://www.hyperactivesw.com
-
- 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
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Poor resizeStack performance when lots of text in scrolling field
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
HyperActive Software | http://www.hyperactivesw.com
Re: Poor resizeStack performance when lots of text in scrolling field
The King James bible, depending on the breaks, has about 780,000 words. That would not even make the beachball appear.
Craig
Craig
-
- 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
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Poor resizeStack performance when lots of text in scrolling field
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.
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
HyperActive Software | http://www.hyperactivesw.com
-
- Posts: 15
- Joined: Tue Apr 04, 2017 8:02 am
Re: Poor resizeStack performance when lots of text in scrolling field
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.
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.