Description: Slow response when typing inside a textbox containing a large amount of text without OpenGL Steps to Reproduce: 1. Open attachment 145512 [details] 2. Enter the textbox 3. Hold Space Actual Results: Choppy slow Expected Results: Smooth changes Reproducible: Always User Profile Reset: No Additional Info: Repro with Version: 6.4.0.0.alpha0+ (x86) Build ID: c45d477b0a0038d9c25176cf7cff299e5ddf3a7a CPU threads: 4; OS: Windows 6.3; UI render: GL; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2019-09-30_05:06:55 Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL and with Versie: 5.3.5.2 Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: standaard; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: CL but not with Versie: 5.2.2.1 Build ID: 3c2231d4aa4c68281f28ad35a100c092cff84f5d CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: standaard; Locale: nl-NL (nl_NL); Calc: CL
Can not really confirm on Windows 10 Home 64-bit en-US with Version: 6.4.0.0.alpha1+ (x64) Build ID: 546e6c359e96a2e7f5aab7c158c7e843be6c8957 CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded About the same 'responsiveness' to text entry at cursor. But certainly slower than doing entry in a paragraph container. Isn't a Draw object "Text box" with this much text content kind of abusive though? I certainly would not be structuring any document like that. As here a rotated Draw object holding text and then expect to have responsive editing of that text? An awful lot of font processing to move cursor or insert spaces character by character. The block selections (<Shift>+<Ctrl>+Home, or End are as fast as one would expect.
If I hold the space bar for a few seconds, the textbox is updated after 2-3 seconds once I've released the space bar Version: 6.4.0.0.alpha0+ Build ID: 3aff00ea2ff704547a4d9fa6e2bb2141eb57bf1d CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug