Thanks you Lagi, Tore and others. Looks like this is specific to Mac OS Big Sur.
I have submitted a bug report: https://quality.livecode.com/show_bug.cgi?id=23139 <https://quality.livecode.com/show_bug.cgi?id=23139> Henry > On Mar 25, 2021, at 4:11 PM, Lagi Pittas via use-livecode > <use-livecode@lists.runrev.com> wrote: > > 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 _______________________________________________ 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