Bug 51547

Yeah, I've seen this recently and its a regression from 3.5.X.

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.

I wonder if this is Linux specific - it continues to appear with SAL_USE_VCLPLUGIN=gen - so not related to recent gtk+ theming changes.

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 ! :-)

at:

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 :-)

works at:

commit 80a921e88a036d42b4b884bb3e0b651fc083c1cd
Author: Andras Timar <atimar@suse.com>
Date:   Mon May 14 22:08:38 2012 +0200

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 :-)

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.

hmm, but that commit is fine ;-) bisecting some more - but it seems some big-gnumake-merge happened in that range ;->

Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b95cfee03ca6eb63eb94593ced389c7f442f2d69

fix fdo#51547: revert "Some cppcheck cleaning"

Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=97ae222bd71716e9b9d4329aa646eddeec9a1c66&g=libreoffice-3-6

fix fdo#51547: revert "Some cppcheck cleaning"


It will be available in LibreOffice 3.6.

Drat after a half-dozen more bisects I discovered that in fact it is: 2f804c94cdaaa9ac047f229509c774dbea1dbcaa

I'll revert that :-)

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.

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 ?).