HI Henry, Tried it on windows LC 9.6.2 RC2 and it works fine.
I still have the problem of very laggy text editor for a machine with 16G of Ram and SSD, there is no scrolling problem on a greater than 5000 line script so it looks like it's big Turd this time ;-) Lagi On Thu, 25 Mar 2021 at 21:09, HENRY LOWE via use-livecode < use-livecode@lists.runrev.com> wrote: > On further investigation this appears to be a problem with any LC > scrolling text field, not just the Script Editor. > > Please try the following and let me know what you observe: > > 1. Create a new stack (e.g. 1024 x 768) > > 2. Add a scrolling text field and resize the field to fill the card. > > 3. Paste enough text (multiple pastes of the same text will do) into the > field so that the vertical scroll bar is activated. > > 4. Place in run mode. Click before the first text character in the field > > 5. Drag-Select text downwards (hold mouse button down while dragging down > over text) towards the bottom of the field until the field begins to > auto-scroll > > 6. Let go of the mouse - the field continues to autoscroll until it > reaches the end of the text > > 7. LC is unresponsive during this automatic scrolling > > 8. On the Mac the Activity Monitor app shows LC consuming 100% of CPU > > 9. This continues for 1-2 minutes then LC unfreezes. > > In a large script I am “locked out” of LC for 10-15 mins as the field > autoscrolls down. > > This may be Mac Big Sur specific, so hopefully someone can test it on that > platform. > > Looks like a bug to me. > > Henry > > > On Mar 25, 2021, at 11:05 AM, Sean Cole (Pi) via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > > RichardG, > > That was a very long way of not answering the question. Very insightful > > regarding the DG though. :) > > It also went a long way of assuming the skill levels of the audience. > Some > > of us are not limited to xTalk level. I understand C++ and why Trevor > > likely coded the DG using such. > > > > My question, just to reestablish, was what on Earth could possibly > > complicate the scrolling of the line-numbers in sync with the main > 'field'? > > Very occasionally the numbers freeze altogether until a click in the > editor > > which is an interesting aside and only partly related to the question. I > > never notice a lag between the two areas. 32-bit I feel is neither here > nor > > there in relation to the syncing or imperceivable lag, especially for the > > SE. > > > > Looking on github reveals that the majority of the code for the SE are > > indeed, as suspected, written in livecodescript (xTalk ;)) by BHall > mostly, > > rather than CPP. And, as suspected, really quite simple and unconvoluted > as > > they can get. Barely anything to become difficult in fixing for Henry's > > listed issue. revsecommoneditorbehavior.livecodescript holds the key, > lines > > 2658-2721 most likely. > > > > Sean > > > > > > On Thu, 25 Mar 2021 at 16:47, Richard Gaskin via use-livecode < > > use-livecode@lists.runrev.com> wrote: > > > >> Sean Cole wrote: > >> > >>> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote: > >>> > >>>> I believe it may be related to the complicated way the line > >>>> number field is kept in sync. > >>> > >>> Quick question. Why would the line number field be complicated? I > >>> can’t imagine anything that would necessitate making it complicated. > >>> Numbers and break points. That’s all it handles, right? > >> > >> > >> It's easy to describe anything in terms that make it sound simple, but > >> whether a task is *actually* simple depends on many things. > >> > >> It's equally an oversimplification to arbitrarily divide the world into > >> two types of programmers, xTalkers and C coders, but that won't stop me > >> from indulging in it here <g>: > >> > >> > >> If we look at text editors made by C coders, they generally only render > >> the line numbers visible on screen given the current scroll position. > >> But they do everything with lower-level/computer-oriented thinking, with > >> lineto and moveto and stringAt (yes, the Inside Macintosh references > >> there show my age, but you know what I mean), so for them these types of > >> calculations are second-nature and not considered tedious at all, it's > >> just how things are done. > >> > >> xTalkers, by virtue of choosing a language that is not only high-level > >> but among the very few that directly incorporate GUI controls as > >> inherent language elements, think differently. To us we put text into a > >> field and set the scroll as we like and let the engine figure out the > >> details. > >> > >> > >> Which is "best" is a topic that can be hotly debated, and was here on > >> this list several years ago in a thread on making text editors in LC. > >> > >> One of the participants in that thread was Jeff Massung, who'd made a > >> very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask > >> the engine to render thousands of lines of line numbers if the script > >> being displayed was much shorter. He felt that the "right" approach > >> would be to do as C programmers do, to dynamically calculate which line > >> numbers should be visible and dynamically populate the line number list > >> with only those on each scrollBarDrag. > >> > >> Others, including myself, felt that using xTalk objects as xTalkers are > >> accustomed to using them was not a mistake at all, but actually quite > >> with-the-grain for xTalk work. Even if we're asking the engine to work > >> harder, we're doing it only once up front, relying on the engine's good > >> buffering to make scrolling throughout the rest of the session simpler. > >> > >> > >> It's worth noting that the excellent DataGrid relies on > >> dynamically-calculated scrolling, but even more worthy to note WHY: > >> > >> It's not because scrolling the DG is made any faster (observably it > isn't). > >> > >> It's because the performance impact of dynamically-calculated scrolling > >> is a NECESSARY tradeoff to cover the sometimes-large number of records > >> it's asked to display. LC uses 32-bit coordinate addressing, which is > >> more than adequate for most things we render since it gives us about 30 > >> feet of drawing space, far bigger than any monitor. But if you try to > >> place tens of thousands of groups nested within a scrolling group, > >> you'll quickly discover what happens when you exceed 32-bit coordinate > >> space. :) > >> > >> So Trevor did the tedious work of providing a profoundly flexible > >> DataGrid, where for the relatively low cost of a modest performance hit > >> during scrolls we can effortlessly display even vast numbers of records, > >> by only actually rendering those on screen at any given time. > >> > >> But the 32-bit coordinate space only applies to controls, not the > >> contents within text fields, so.... > >> > >> > >> Back to the LC Script Editor, truth be told it's been so long since I > >> donned my pith helmet to dive into its code jungle that I'm not in a > >> position to speak authoritatively on how it's constructed. > >> > >> But we can observe (sadly, without much effort) a lag between scrolling > >> the script field and the subsequent update of the line number list. In > >> some cases, depending on platform and script length, this lag is more > >> easily seen than on others. > >> > >> This suggests that there's a lot more going on with the SE's line number > >> update than just setting its scroll to match the editor field's. > >> > >> Indeed, given the variance of the lag it would seem it's not updated > >> directly at all, but perhaps via "send". > >> > >> > >> It wouldn't be appropriate to say the LC implementation is necessarily > >> "wrong" or even "bad". It's a deeply complicated layout with a lot of > >> updates to manage, and given the vast scope of its design ambitions it's > >> hard to say what one "should" do there. > >> > >> But it is safe to observe that it was written by people who cut their > >> teeth on languages more lower-level than xTalk. Aside from Monte and > >> Kevin, I don't know of anyone there who shipped a product using an xTalk > >> before being hired to make an xTalk. > >> > >> Obviously, that's exactly what we want in an engine team, C++ engineers > >> who live and breathe deep computer science. > >> > >> But from time to time it does lend itself toward designs and > >> implementations that look like the work of native C coders rather than > >> native xTalkers. These strengths give us a beautiful engine, and an IDE > >> that could probably benefit from some trimming. > >> > >> > >> xTalk is a funny thing, and it's not easy coming up with a concise rule > >> set for what constitutes good with-the-grain savvy of The xTalk Way. > >> > >> But we know it when we see it. And line numbers that lag behind editor > >> field scrolls may be an example where The Zen of The xTalk Way might > >> produce a smoother solution. > >> > >> -- > >> Richard Gaskin > >> Fourth World Systems > >> > >> _______________________________________________ > >> use-livecode mailing list > >> use-livecode@lists.runrev.com > >> Please visit this url to subscribe, unsubscribe and manage your > >> subscription preferences: > >> http://lists.runrev.com/mailman/listinfo/use-livecode > >> > > _______________________________________________ > > use-livecode mailing list > > use-livecode@lists.runrev.com > > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > > http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- KIndest Regards Lagi _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode