Bug 51547 - PresenterConsole - speaker screen corrupted
Summary: PresenterConsole - speaker screen corrupted
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected)
Hardware: All Linux (All)
: medium blocker
Assignee: Not Assigned
Whiteboard: target:3.7.0
Depends on:
Blocks: mab3.6
  Show dependency treegraph
Reported: 2012-06-29 01:35 UTC by Jean-Baptiste Faure
Modified: 2012-07-05 01:48 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:
Regression By:


Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Baptiste Faure 2012-06-29 01:35:05 UTC
Steps to reproduce:
- connect a second screen like a video-projector
- start a slideshow -> presenter screen start
Main problem: on the speaker screen the current slide is not visible but a very
short time during transition.
Second problem: on the speaker screen only the clock is visible at the bottom.

Tests done on LO 32 bits on Ubuntu 10.04 LTS (gnome 2) -> same
problem as experienced with LO last week on Ubuntu
11.10 x86_64 with gnome-shell.

Best regards. JBF
Comment 1 Caolán McNamara 2012-06-29 02:13:10 UTC
Yeah, I've seen this recently and its a regression from 3.5.X.
Comment 2 Michael Meeks 2012-07-03 03:41:08 UTC
Not related to my:

From fcab3edbac4985d7f110732dfdf67a449876ae01 Mon Sep 17 00:00:00 2001
From: Michael Meeks <michael.meeks@suse.com>
Date: Wed, 30 May 2012 16:45:10 +0100
Subject: [PATCH] presenter-console: cleanup and simplify threading mess
 around timers.

At least it continues to behave the same without that; odd.
Comment 3 Michael Meeks 2012-07-03 03:49:01 UTC
I wonder if this is Linux specific - it continues to appear with SAL_USE_VCLPLUGIN=gen - so not related to recent gtk+ theming changes.
Comment 4 Michael Meeks 2012-07-03 04:49:29 UTC
Interestingly, this appears unrelated to the sdext/ code itself - if I import the -3-5 code for the presenter view, and hack the makefiles to build it vs 3.6 I get exactly the same screen corruption / re-drawing issue.

ie. some behaviour elsewhere must have changed; it'd be lovely if we could bibisect that out I guess.

It appears unrelated to cairo / use-hardware-acceleration etc. It appears re-drawing / invalidation is what breaks things - the clock triggers this for the toolbar initially.

Interesting ! :-)
Comment 5 Michael Meeks 2012-07-03 06:50:47 UTC

commit 8945f1bc858f3636d4270f16bd2e66ce88c0021c
Author: Stephan Bergmann <sbergman@redhat.com>
Date:   Mon Mar 26 11:58:51 2012 +0200

it works well, if we fix the install issues; binary chopping further :-)
Comment 6 Michael Meeks 2012-07-03 08:28:45 UTC
works at:

commit 80a921e88a036d42b4b884bb3e0b651fc083c1cd
Author: Andras Timar <atimar@suse.com>
Date:   Mon May 14 22:08:38 2012 +0200
Comment 7 Michael Meeks 2012-07-03 09:36:52 UTC
and by:

commit b255de87082d11a42d7af7860dcc4e971342df06
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Tue Jun 5 18:14:52 2012 -0500

it is broken - narrowing it to ~1200 revisions :-)
Comment 8 Michael Meeks 2012-07-03 14:08:19 UTC
Breakage introduced between these two:
	+ 03764e29978bcf0b59a3738166b5af31d0af582a # works - May 24th
	+ b6ce391171e417199d33ae085d2f0768a3e952b3 # busted - May 29th

~300 commits. I'm personally most suspicious of:

commit 2f804c94cdaaa9ac047f229509c774dbea1dbcaa
Author: Julien Nabet <serval2412@yahoo.fr>
Date:   Mon May 28 20:50:07 2012 +0200

which has some rather unsafe looking local variable movements.
Comment 9 Michael Meeks 2012-07-03 14:22:09 UTC
hmm, but that commit is fine ;-) bisecting some more - but it seems some big-gnumake-merge happened in that range ;->
Comment 10 Not Assigned 2012-07-04 08:17:36 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":


fix fdo#51547: revert "Some cppcheck cleaning"
Comment 11 Not Assigned 2012-07-04 08:24:27 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":


fix fdo#51547: revert "Some cppcheck cleaning"

It will be available in LibreOffice 3.6.
Comment 12 Michael Meeks 2012-07-04 08:26:27 UTC
Drat after a half-dozen more bisects I discovered that in fact it is: 2f804c94cdaaa9ac047f229509c774dbea1dbcaa

I'll revert that :-)
Comment 13 Julien Nabet 2012-07-04 12:11:29 UTC
It's entirely my fault here, I apologize for this :-(
Thank you Jean-Baptiste for having filled this bug.
Thank you Michael for the time spent on the investigation/fix.
Comment 14 Michael Meeks 2012-07-05 01:48:45 UTC
Hey - it's fine - just a cppcheck bug lets get it filed/fixed :-) and we can re-commit at least two of the three hunks of that nice cleanup anyway (could you do that ?).