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 ?).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.