In order to reproduce the bug: [1] Start LibreOffice. Some recent documents should be displayed as thumbnails. If not open some files and close them again. [2] Move the mouse pointer slowly from the menu bar down to the first thumbnail. Stop moving when the thumbnail is selected. The path and file name is displayed as tip. [3] Go on moving down. Every time when the mouse pointer reaches the tip the thumbnail flickers once and the tip is displayed a bit more down. Expected: No flicker. [4] If you perform steps 2 and 3 faster the thumbnail flickers serveral times, which is quite irritating. Comments: (a) The flickering exists already since version 4.2.0, but it was not very obvious. With the change of the background colour (version 5.0.0.5) to dark grey the flickering becomes more distinct. (b) I'm not sure if the position of the tip should change during moving the mouse pointer above a thumbnail. I think a fixed position (e.g. below the thumbnail, similar to tips of icons of the symbol bars) would be better. OS: Win7, 32 Bit, LO: 5.0.0.5
Reproducible with Version: 5.1.0.0.alpha1+ (x64) Build ID: e92a8b92072284fd7c37d7bb3e1e8fe72a185f35 TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-22_21:46:26, win7
Yes, there is a noticeable flash during redraw. Believe it is an ongoing buffering issue, more noticeable at 5.0 release with change in StartCenter color scheme. None the less this is clearly a duplicate/continuation of bug 71807 *** This bug has been marked as a duplicate of bug 71807 ***
I'm sorry but I think there is a mistake. From my point of view there is no relationship between this bug and bug 71807 [Drawings (in Writer) embedded in document corrupted on saving. Rest of document is fine.]. May be another bug is meant. Hence set Status back to NEW.
Sorry that of course should have been dupe of bug 71087 *** This bug has been marked as a duplicate of bug 71087 ***
No, confirming and setting this back to new. The issue is a canvas refresh, but it looks to come from movement of the Tooltip containing full file path. As cursor is moved, the Tooltip repositions and causes the entire thumbnail view canvas to be redrawn. If you check on Tools -> Options -> General: Extended Tooltips, which without local help installed shows a generic tooltip for the thumbnail views that does not reposition as the mouse moves. There is no "flash" as the mouse traverses the frame.
@Kendy, Can the drawing of the tooltip on mouse movement be adjusted to not also refresh the active thumbnail?
Have another aspect to the canvas redraw while the mouse cursor moves and the tool tip pop-up follows it. As cursor is moved, and tooltips with file name and path are redrawn to follow along, the old border from the tooltip is not being erased. Results in a ~1px white line for each tooltip as it relocates that was the old top edge and right edge of the tooltip. That ~1px line remains until the whole canvas is redrawn with a scroll bar movement or selection of a document or activation of a module.
(In reply to V Stuart Foote from comment #5) > If you check on Tools -> Options -> General: Extended Tooltips, which > without local help installed shows a generic tooltip for the thumbnail views > that does not reposition as the mouse moves. There is no "flash" as the > mouse traverses the frame. This is different on my system (German UI, German local help installed(!), extended tool tips checked): The german generic tool tip is displayed. If you 'touch' this tool tip with the mouse pointer the position of the tool tip changes and the canvas also flickers in this case. Furthermore with extended tool tips checked and local help installed, the flickering also occurs if you display the templates within the start center and 'touch' the displayed tool tip.
(In reply to Harald Koester from comment #8) > > without local help installed shows a generic tooltip... > > This is different on my system (German UI, German local help installed(!), > extended tool tips checked): The german generic tool tip is displayed. If > you 'touch' this tool tip with the mouse pointer the position of the tool > tip changes and the canvas also flickers in this case. > Yes I see that also, but I have to work to get the generic tooltip to appear at a location over a thumbnail. Point was, that if the local help is not installed, by checking extended tips it is more obvious the issue is screen flash related to the canvas redraw of repositioned tooltips moving in response to the mouse movements. The generic tip that shows with extended tips selected is for the whole StartCenter and does not get bumped around--as much--by mouse cursor movements.
Created attachment 118450 [details] zip of a CamStudio AVI movie showing 1px residual Screen capture video of 1px top and right edge of file path and name tool-tip leaving a trail as is pushed down across its thumbnail view on the StartCenter.
On Windows 10 Pro 64-bit en-US with Version: 5.1.0.0.alpha1+ Build ID: d417059dae303685de7aa0f4b1c192ffcf5304d5-GL TinderBox: Win-x86@39, Branch:master, Time: 2015-09-05_09:23:01 Locale: en-US (en_US) When Tools -> Options -> View: "Use OpenGL for all rendering" is turned off, the tool-tip does not leave a trail.
This also happens in the template manager (file->templates->manage in writer)
With OpenGL active tooltips or file path "tip" are "off by one" when cleared as the tip is moved with mouse pointer movement. Leaving trails across the StartCenter until the screen is refreshed or resized. The flickering on redraw is momentary--but the trails are persist. When OpenGL rendering is disabled--the tooltips or file path "tip" is correctly disposed as the next is drawn. The "flicker" also is gone. On Windows 8.1 Pro 64-bit Version: 5.2.0.0.alpha0+ Build ID: ebe80ac6713b67b1801ede3d1e9038cb2c93cb11 Threads 8; Ver: Windows 6.2; Render: GL; Also, on Fedora 23 32-bit with Version: 5.0.3.2 Build ID: 5.0.3.2-4.fc23-GL Locale: en-US (en_US.UTF-8)
I have a fix for this =) for 5.1 / master - it removes all flicker. Will push shortly.
Michael, * On Windows 10 Pro 64-bit with Version: 5.2.0.0.alpha0+ Build ID: 917d59a84124d1022bd1912874e7a53c674784f1 CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-12_12:17:04 Locale: en-US (en_US) The tool-tips display of file name is still leaving a trail of redraw edges as it is pushed by mouse down the backing pane of the thumbnail view of Start Center. Also, don't see too much reduction in the "flicker" as each thumbnail is redrawn as the tool-tip repositions. It only occurs when OpenGL is active, but may be a different facet than the double buffering you've been working on?
Hah - so my patch removes GL related flicker; but for this case, it's un-related to GL AFAICS and was here from 4.2.0 ... so ;-) The re-paint dirt is another bug that got tangled into here; but the flickering is prolly easy enough to fix - will have a look =) Thanks !
On Fedora 23 w/LXDE (as guest on VMWare Workstation 12 on Windows 8.1) and Version: 5.2.0.0.alpha0+ Build ID: 8a342e9f6ad701bd46ecca1c3d270ef2d9670d44 CPU Threads: 1; OS Version: Linux 4.2; UI Render: GL; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2015-12-16_12:23:28 Locale: en-US (en_US.UTF-8) The flicker while redrawing each thumbnail is, at this point following Michael's patch, not as noticeable as under windows. However the tooltip filename ghost behaves the same. Present until the StartCenter is resized or redrawn by component launch. When OpenGL is disabled the "ghosting" of the tooltip frame vanishes. As in movie clip comment 10. Unfortunately for this build, no opengl_device.log being written to settings/cache directory.
On Windows 8.1 Pro with Version: 5.2.0.0.alpha0+ Build ID: 4a8c0d313540bd78c9c381edd548b976c580ca9a CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-04_02:00:52 Locale: en-US (en_US) The off by one of the tooltip has been eliminated! Thumbnail views on backingwindow are clean. Any "Flicker" is gone--except for the still noticible redraw of the onmouseover background for the active thumbnail. As mouse cursor is repositioned, the tooltip is redrawn in a new location. That triggers a clear and apply of the onmouseover background. Might look like a "flicker", but it clearly follows the redraw of the moving tooltip.
The ghosting / off-by-one error is fixed as bug#96858. Tor is tackling OpenGL related flicker under Windows in a similar way as for gtk+ too. Glad it's working nicely under Linux for you (though to use GL under Linux you need SAL_USE_VCLPLUGIN=gtk - gtk3 erroneously claims it is working, when it is not ;-)
This flicker might be a generic problem with thingies that are displaying a tooltip. If you slowly move the mouse cursor between tool icons in the toolbar of Writer, for instance, so that the tooltip stays visible (and its contents switches as you move the cursor between icons), you will notice, now and then, that the icon you are leaving and/or entering flickers. Probably it is much more noticeable for the start centre thumbnails just because they are much larger and take a little longer to draw.
... but in the case of toolbar icons, I see the flicker only when not using OpenGL. So maybe not the same root cause after all.
Checked again with version 5.1.0.3, Win 7: Bug still exists with and without using OpenGL. Also the flickering described in comment 8 still exists.
And as in comment 18, and initial description, this is now exclusively an issue of redrawing the thumbnail view or icon when mouse over focus shifts or as the tool tip is being repositioned. It is normal, consistent and is acceptable given that that portion of the canvas is being redrawn. It is less noticiple in OpenGL because it is accelerated, and it is not overly objectionable as it is rather hard to reproduce--slowly pushing the tool-tip to force the redraw of that thumbnail is hardly a normal action. I'd say it is good enough and be done with it -- believe we can close WONTFIX. Alternative of "anchoring" the tool-tip is much less appealing.
Happy to leave it open if someone wants that but un-CC'ing the GL guys =) I don't see us having time to fix the minor cosmetic thing anytime soon.
@Kendy, With OpenGL issues resolved (reworked buffering and effective black listing), would there be a lot of work in providing less graphically demanding mouse over behavior on the Start Center and Template Manager backingwindow, and for tooltip movement, for when hardware acceleration is not active or is blocked? If not, suggest we close residual as WONTFIX.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Bug still exists in version 5.3.0 with Win7 and OpenGL disabled.
*** Bug 102527 has been marked as a duplicate of this bug. ***
https://gerrit.libreoffice.org/51930 fixes this on Windows.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fec7dc8d4b82cc9a60d8625f313ba12d926665b5 tdf#93120: Avoid redraws when mouse enters tooltips (Win) It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping to Mike Kaganski: is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Thanks
(In reply to Xisco Faulí from comment #31) No, the last commit is for Windows only, and I'm not working on the other platforms.
Repro the flicker while chasing tooltip. GTK3 works fine. Arch Linux 64-bit Version: 6.1.0.0.alpha1+ Build ID: 632bc11ce8fab1c4046ab24810b90a7ce9ac5914 CPU threads: 8; OS: Linux 4.16; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on April 27th 2018
Verified with version 6.1.2 (64 bit) with Windows 10.
let's close it as FIXED. You fell free create a new bugreport about tooltips flickering I checked it in Version: 6.3.0.0.alpha1+ Build ID: 6d6277f23337c8eae9acabdf830e33fcc3ee9923 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
I'm not seeing the flicker on Linux + kde5. On Windows, I can see it, if I move the mouse quite fast back and forth between 3 thumbnails.