| Summary: | Sidebar: editing page margins is very laggy, with high CPU load | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | Mihkel Tõnnov <mihhkel> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | jmadero.dev, jorendc, philipz85, vsfoote |
| Priority: | medium | ||
| Version: | 4.2.0.3 rc | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=76002 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 103428 | ||
|
Description
Mihkel Tõnnov
2014-02-11 11:00:50 UTC
I fail to reproduce, tested using Mac OSX 10.9 with LibreOffice 4.2.0.4. Kind regards, Joren Two more machines that cannot reproduce: Ubuntu 13.10 LibreOffice 4.2.1.1 release GNOME3 Ubuntu 12.04 GNOME3 LibreOffice 4.2.1.1 release Both the page margins work quite quickly, one is an i7 quad core but the other one is an older machine that shows no lag at all. Marking as WFM @Mihkel - please try with 4.2.1.1 release, if you still see the lag mark as UNCONFIRMED and we'll try to find another tester One more thing - cannot type values on any of the test machines - so that should be a new bug report as it's a separate issue Tried with 4.2.1.1, still laggy for me: if I scroll any margin field there, the value first changes by 0,1, then freezes while the page margin moves, then jumps to the final value (which then usually needs further adjusting). Setting as UNCONFIRMED, as requested. (In reply to comment #3) > One more thing - cannot type values on any of the test machines - so that > should be a new bug report as it's a separate issue Filed bug 76002. On Windows 7 sp1, 64-bit no notable lag when resizing also no issue with direct text entry of margins in roll boxes. Will annotate bug 76002 accordingly. Version: 4.2.0.4 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71 nor on Version: 4.3.0.0.alpha0+ Build ID: 0919979bd1da3379e030b353a097d8fe1fd8341a TinderBox: Win-x86@39, Branch:master, Time: 2014-03-10_01:36:32 So no impact on Windows. Will poke at a Linux in a bit. On Linux (Fedora 20) 3.11.10-301.fc20.x86_64 with GNOME 3 DTE and Version: 4.2.1.1 Build ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b I see no delay or lag when using the widgets in the Sidebar 'Page' Content Panel where the predefined 'Narrow', 'Normal', 'Wide' and 'Mirrored' settings are immediately applied to repaint the document page. I see the same immediate effect with changes to the 'Left', 'Right', 'Top' and 'Bottom' spinners. Can confirm the issue of bug 76002. QA administration -- revised summary to reflect split off of bug 76002 for me also not reproducible with LO 4.3.2.2 (Win 8.1) Mihkel, is this issue occurring for you just regularly scrolling? The only way I was able to reproduce this was by scrolling extremely fast (by setting my mouse's scroll resistance off). I'm on LO 4.3.3.2 stable. Either way, I _could_ reproduce. I'm marking this bug as NEW, but it may be resolved as INVALID by a developer if it turns out that this is reasonable behavior for the amount of input events being generated (which wouldn't surprise me). Not happening for me on my 8 year old laptop. @Mihkel: Please provide additional information on how this can be confirmed. Version: 5.1.0.0.alpha1+ Build ID: 25534a62b2ba398c6298c6b9e521f20de1087540 TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-08-07_14:13:33 Locale: en-US (en_US.UTF-8) I can no longer reproduce this lag with KDE4 in Mageia 5 (running on the same computer as before). So possibly it is/was an issue stemming from KDE3/GTK2 on my old OS (Debian Lenny). Marking as WorksForMe, as it doesn't make much sence to try and get it working lag-free on a near-ancient OS/DE :) |