47 mpBufferDevice->SetOutputSizePixel(getOutputDevice().GetOutputSizePixel(), false); Allocates a buffer of this size: 1789x956 To render a 256x256 pixel square tile ;-) which seems ... curious in the extreme, and potentially rather wasteful as well =) Command-line is: LO_TRACE='gdb --args' bin/run tilebench /opt/libreoffice/master/instdir/program/ /tmp/helloworld.odt where helloworld.odt is a small file containing "Hello World" Backtrace is like this: #0 0x00007fffeaa2fd48 in sdr::overlay::OverlayManagerBuffered::ImpPrepareBufferDevice() (this=0x13ef680) at /data/opt/libreoffice/master/svx/source/sdr/overlay/overlaymanagerbuffered.cxx:47 #1 0x00007fffeaa30822 in sdr::overlay::OverlayManagerBuffered::ImpSaveBackground(vcl::Region const&, OutputDevice*) (this=0x13ef680, rRegion=..., pPreRenderDevice=0x131b410) at /data/opt/libreoffice/master/svx/source/sdr/overlay/overlaymanagerbuffered.cxx:161 #2 0x00007fffeaa31878 in sdr::overlay::OverlayManagerBuffered::completeRedraw(vcl::Region const&, OutputDevice*) const (this=0x13ef680, rRegion=..., pPreRenderDevice=0x131b410) at /data/opt/libreoffice/master/svx/source/sdr/overlay/overlaymanagerbuffered.cxx:419 #3 0x00007fffd247d22c in (anonymous namespace)::RenderContextGuard::~RenderContextGuard() (this=0x7ffffffbd300, __in_chrg=<optimized out>) at /data/opt/libreoffice/master/sw/source/core/view/viewsh.cxx:1709 #4 0x00007fffd247db20 in SwViewShell::Paint(OutputDevice&, Rectangle const&) (this=0x12c3b10, rRenderContext=..., rRect=Rectangle = {...}) at /data/opt/libreoffice/master/sw/source/core/view/viewsh.cxx:1848 #5 0x00007fffd1b5c3b4 in SwCursorShell::Paint(OutputDevice&, Rectangle const&) (this=0x12c3b10, rRenderContext=..., rRect=Rectangle = {...}) at /data/opt/libreoffice/master/sw/source/core/crsr/crsrsh.cxx:1278 #6 0x00007fffd247e183 in SwViewShell::PaintTile(VirtualDevice&, int, int, int, int, long, long) (this=0x12c3b10, rDevice=..., contextWidth=256, contextHeight=256, tilePosX=0, tilePosY=0, tileWidth=12474, tileHeight=17406) at /data/opt/libreoffice/master/sw/source/core/view/viewsh.cxx:1907 #7 0x00007fffd2861235 in SwXTextDocument::paintTile(VirtualDevice&, int, int, int, int, long, long) (this=0x7fffd8b18508, rDevice=..., nOutputWidth=256, nOutputHeight=256, nTilePosX=0, nTilePosY=0, nTileWidth=12474, nTileHeight=17406) at /data/opt/libreoffice/master/sw/source/uibase/uno/unotxdoc.cxx:3111 #8 0x00007fffee7d4a50 in doc_paintTile(LibreOfficeKitDocument*, unsigned char*, int, int, int, int, int, int) (pThis=0x1123e00, pBuffer=0x7ffffffbdaf0 '\001' <repeats 15 times>, "\002\002\002\002\004\002\002\002\004\003\003\003\006\004\004\004\a\004\004\004\a\004\004\004\a\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b\004\004\004\b"..., nCanvasWidth=256, nCanvasHeight=256, nTilePosX=0, nTilePosY=0, nTileWidth=12474, nTileHeight=17406) at /data/opt/libreoffice/master/desktop/source/lib/init.cxx:924 I assume it is picking up a window size, from a (hidden) window that is ~irrelevant to the size of the output device we should be rendering into. I guess a more careful selection of outputdevice - not fetched from the window, but as-passed-in would be helpful there =)
Hmm, for me, in a ssh session with no X, it allocates an 1x1 buffer, not a 1789x956 (or other large size) one.
But indeed, in an X session, I see a large buffer size.
A trivial and silly "fix" would of course be to make sure to unset $DISPLAY when running unit tests (and LibreOfficeKit-using processes)... Would prevent OpenGL use, though, wouldn't it?
The size comes from the previous Writer document window size as stored in the persistent user configuration, framework/source/helper/persistentwindowstate.cxx etc. Would need a way to ignore such in unit tests (and LibreOfficeKit programs). (Ideally we would need a way for LibreOfficeKit programs to run without reading (and even less writing) any user-specific configuration at all.)
Ah =) so perhaps this cairo / headless-ness stuff is just a waste of time then =) no idea - anyhow - thanks for chasing.
Suggested patch: https://gerrit.libreoffice.org/#/c/22233/ . Works for me.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=882d27fce20ee0537f785a619be1dd065ea6bbca tdf#97435: Avoid persistent window state crack when headless 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.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cede4a1af316b9a9e1928c71082448ff087d288b Revert "tdf#97435: Avoid persistent window state crack when headless" 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.
Had to revert it because it caused some of the Java unit tests to fail. This seems to be because of the getBounds() method of some object returning a zero-sized rectangle. I wonder if it would be better in the patch to test for comphelper::LibreOfficeKit::isActive(), not Application::IsHeadlessModeEnabled()?
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=574482123b0fcd7deed9345fd524e9fc1d8bfb5e tdf#97435: Avoid persistent window state crack when used from LibreOfficeKit 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.
Change request for the 5-1 branch at https://gerrit.libreoffice.org/#/c/22260/
Hi, Is this bug fixed? If so, could you please close it as RESOLVED FIXED? Regards
looks closed to me; thanks ! =)