Created attachment 120309 [details] screenshot OpenGL -> OFF tested under Win8.1 x64 using 5.1.0.0.alpha1+ Build ID: c81142b277546714c0dfa8f9c2961c8ef80bc6d2-GL TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-04_23:17:48 Locale: it-IT (it_IT) STEPS TO REPRODUCE 1- load the autocorrect replacement table (Tools/Autocorrect/Autocorrect options/Replace 2- resize the table the table background will partially turn black when you resize it. is is a nasty side effect of the fix for Bug 95352 ?
Reproduced: it turns black during resizing, if I have OpenGL enabled. Long enough that one might grab a screenshot. Even the whole dialog area might turn black. It flashes black very quickly, if OGL is not on. Asus T100TA (hybrid laptop) Win 8.1 32-bit LibO Version: 5.1.0.0.alpha1+ Build ID: db6a928a420868b2a80ba11c8d46151d16c13624-GL TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-11-05_22:13:24 Locale: fi-FI (fi_FI)
still reproducible using LibO 5.2.0.0.alpha0+ Build ID: 51a5dfd783bfc1efc52a791aab4114039581252f Threads 4; Ver: Windows 6.2; Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-04_10:49:33 Locale: it-IT (it_IT) issue is present even if OpenGL is off
still present in LibO 5.2.0.0.alpha0+ Build ID: 22e5170af74c635cf55d089f97946b6dc86f82ad CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-01-05_23:41:26 Locale: it-IT (it_IT)
We should not flash black anymore; perhaps a white background; Beluga reports: commit 6c8fffdf4f968b4838dc4cb3d5161631877b0ebd Author: Michael Meeks <michael.meeks@collabora.com> Date: Tue Jan 12 21:13:13 2016 +0000 bug#96385 - opengl: dynamically adjust priority of swap buffers. Which fixes the auto-correct flicker for me. Thanks for reporting ! =)
bug is still present under Win8.1 x64 using LibO 5.2.0.0.alpha0+ Build ID: 70ea14baf7d43c00f73807bce13629ca25320558 CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-13_23:55:07 Locale: it-IT (it_IT) I'll retest tomorrow if a newer build is available, but I'm afraid the issue is not solved yet since your committ date is about Jan 12 and should already be in master
Created attachment 121947 [details] screenshot OpenGL -> ON
retested under Win8.1 x64 using LibO 5.2.0.0.alpha0+ Build ID: f0841c6c86c8c8403eb1d78a1bd43a8adac75e3a CPU Threads: 4; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-15_00:01:41 Locale: it-IT (it_IT) OpenGL -> OFF same black background at resize as in attachment 120309 [details] OpenGL -> ON red and purple background at resize as in attachment 121947 [details] so the issue is not fixed and it's even worse than before I revert status to NEW
The red and the purple are debugging aids and in a production build both colours would be white.
thanks for explaining the meaning of that colors.
OGL - ON: I still get the black bg. Win 8.1 32-bit Version: 5.2.0.0.alpha0+ Build ID: f0841c6c86c8c8403eb1d78a1bd43a8adac75e3a CPU Threads: 4; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-01-15_00:01:41 Locale: fi-FI (fi_FI)
Beluga: > It flashes black very quickly, if OGL is not on. This sounds more like a rendering performance issue then (?) Certainly as you expand the size of the window - you'll see some black in the un-rendered area; but that's true of GDI. Certainly with debugging on we try to flash red like that to highlight a potential issue =) so in DBGUTIL mode things will be worse - and we also glClearColor the background randomly - and also GL rendering will be somewhat slower so ... =) I guess its best to test for these things without dbgutil. But will look more closely at this particular dialog for sure ...
(In reply to Michael Meeks from comment #11) > Beluga: > > It flashes black very quickly, if OGL is not on. > > This sounds more like a rendering performance issue then (?) Certainly as > you expand the size of the window - you'll see some black in the un-rendered > area; but that's true of GDI. Certainly with debugging on we try to flash > red like that to highlight a potential issue =) so in DBGUTIL mode things > will be worse - and we also glClearColor the background randomly - and also > GL rendering will be somewhat slower so ... =) I guess its best to test for > these things without dbgutil. But TB62 builds should not be with dbgutil. Even new TB39 builds have appeared to have not been dbgutil indicated by the traces I have done.
to get the colors - its necessary to have dbgutil turned on. The most interesting thing about Tommy's image in attachment2 is the vcl::Cursor artifact in it [!] the cursor rendering there is almost certainly triggered by some timeout that races the re-rendering and wins in his case - but not in other people's =) that combined with a slow re-rendering of some quite heavy widgets in there almost certainly causes this issue.
still present in 5.2.0.0.alpha0+ Build ID: f01bac5cc2b54b6df731b45c46187fec12515b46 CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-02-14_00:02:05 Locale: it-IT (it_IT)
Marco Cecchetti committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7fdc29469d3d098c1b2d5b1cfc7ed907031eb932 tdf#95616 - fix flickering issue It will be available in 5.2.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.
Of course; the reason for the flash is the relatively slow rendering of this dialog - something we can't easily fix without some profiling & thought; but we can stop it flickering at least =) Thanks !
Marco Cecchetti committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e19212b0854d963d33354095ffa62e34ac56d315&h=libreoffice-5-1 tdf#95616 - fix flickering issue It will be available in 5.1.2. 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.
sorry to REOPEN but I still see the transient black background while resizing the autocorrect replacement table. I've just retested under Win8.1 x64 using: LibO 5.2.0.0.alpha0+ Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa CPU Threads: 4; OS Version: Windows 6.29; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35 Locale: it-IT (it_IT) the bug shows up when OpenGL is ON
> sorry to REOPEN but I still see the transient black background while > resizing the autocorrect replacement table. Hmm - I see no flicker here; it is certainly the case - that when we re-size a window - depending on how fast it renders; we can get a delay before it is fully rendered; and you get dead colored space there. If I re-size writer even with a trivial / empty document without GL enabled eg. I get grey regions around the document until it re-renders. Having black there is reasonably expected; the flicker is what (I thought) this bug was about - and is fixed. That we don't render everything instantly is ... reasonably normal =) So - for example turn off GL - and load a complex/3D drawing shape in 'draw' - and then re-size the window. I get black flicker there ;-) So - we focused on the flickering; which was a regression. Now - ideally; we would forcibly render all of the content before swapping buffers in the OS 'Paint' event - and then we'd get a very silky smooth experience [ although you really can't win - this will make re-sizing of complex windows 'jerky' instead ;-].
(In reply to Michael Meeks from comment #20) > > sorry to REOPEN but I still see the transient black background while > > resizing the autocorrect replacement table. > > .... > > Having black there is reasonably expected; the flicker is what (I thought) > this bug was about - and is fixed. > ... > So - we focused on the flickering; which was a regression. > ... sorry Micheal but this is not correct... the bug report has always been about the "transient black background when resizing"... so, it's good news you fixed the "flickering" thing but the "black bacground" issue still persists > Now - ideally; we would forcibly render all of the content before swapping > buffers in the OS 'Paint' event - and then we'd get a very silky smooth > experience [ although you really can't win - this will make re-sizing of > complex windows 'jerky' instead ;-]. I don't know... we should try to see which solution is better to the user's eye... black or jerky.
retested under Win8.1 x64 bug is still present in LibO 5.1.5.2 and 5.2.1.2 but is gone in LibO 5.3.0.0.alpha0+ Build ID: 4c70a1a6666a079872b8f1966bd398e924dc1d1a CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-09-22_06:54:24 Locale: it-IT (it_IT); Calc: groupand so the bug is RESOLVED WORKSFORME in 5.3.x branch.