I have followed your recipe and I can confirm that this is a problem also with ordinary scrolling fields in LC 9.6.2 (rc3). It does not seem to be a problem in LC 9.6.2 (rc1).
Best regards Tore Nilsen > 25. mar. 2021 kl. 22:07 skrev HENRY LOWE via use-livecode > <use-livecode@lists.runrev.com>: > > 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 _______________________________________________ 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