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 3.6.0.0.beta2 32 bits on Ubuntu 10.04 LTS (gnome 2) -> same problem as experienced with LO 3.6.0.0.beta2+ last week on Ubuntu 11.10 x86_64 with gnome-shell. Best regards. JBF
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 ?).