Bug Hunting Session
Bug 95616 - autocorrect replacement table has transient black background when resized
Summary: autocorrect replacement table has transient black background when resized
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.1.0.0.alpha1
Hardware: Other Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.1.2
Keywords:
Depends on:
Blocks: 96385
  Show dependency treegraph
 
Reported: 2015-11-05 20:59 UTC by tommy27
Modified: 2016-10-06 21:01 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot OpenGL -> OFF (66.56 KB, image/jpeg)
2015-11-05 20:59 UTC, tommy27
Details
screenshot OpenGL -> ON (3.38 KB, image/png)
2016-01-15 06:21 UTC, tommy27
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tommy27 2015-11-05 20:59:11 UTC
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 ?
Comment 1 Buovjaga 2015-11-06 14:42:52 UTC
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)
Comment 2 tommy27 2015-12-08 08:49:26 UTC
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
Comment 3 tommy27 2016-01-10 09:48:35 UTC
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)
Comment 4 Michael Meeks 2016-01-13 10:36:28 UTC
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 ! =)
Comment 5 tommy27 2016-01-14 06:36:20 UTC
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
Comment 6 tommy27 2016-01-15 06:21:42 UTC
Created attachment 121947 [details]
screenshot OpenGL -> ON
Comment 7 tommy27 2016-01-15 06:24:00 UTC
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
Comment 8 Tor Lillqvist 2016-01-15 06:37:33 UTC
The red and the purple are debugging aids and in a production build both colours would be white.
Comment 9 tommy27 2016-01-15 10:31:12 UTC
thanks for explaining the meaning of that colors.
Comment 10 Buovjaga 2016-01-15 15:39:27 UTC
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)
Comment 11 Michael Meeks 2016-01-16 11:04:02 UTC
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 ...
Comment 12 Buovjaga 2016-01-17 16:25:06 UTC
(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.
Comment 13 Michael Meeks 2016-02-11 09:41:30 UTC
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.
Comment 14 tommy27 2016-02-14 08:25:50 UTC
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)
Comment 15 Commit Notification 2016-03-14 11:11:20 UTC
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.
Comment 16 Michael Meeks 2016-03-14 12:38:37 UTC
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 !
Comment 17 Commit Notification 2016-03-14 12:40:01 UTC
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.
Comment 18 tommy27 2016-03-19 07:07:33 UTC
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
Comment 19 Michael Meeks 2016-03-19 14:36:54 UTC
> 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 ;-].
Comment 20 Michael Meeks 2016-03-19 14:36:54 UTC Comment hidden (obsolete)
Comment 21 tommy27 2016-04-03 05:33:12 UTC
(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.
Comment 22 tommy27 2016-10-06 21:01:05 UTC
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.