https://bugs.documentfoundation.org/show_bug.cgi?id=174143
Bug ID: 174143
Summary: LOK on Windows: Calc paintTile returns an opaque black
tile since SalVirtualDevice::SetSizeUsingBuffer no
longer falls back to SetSize
Product: LibreOffice
Version: 25.8.0.0 alpha0+
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: graphics stack
Assignee: [email protected]
Reporter: [email protected]
Regression from: 2507d08388dd "split the SetSizeUsingBuffer code paths"
(2025-01-16)
Version field: 25.8.0.0 alpha0+ (tested: 25.8.7.3, 26.2.7.1, 26.8.1.1 affected;
25.2.7.2 works)
With a Calc document loaded through LibreOfficeKit on Windows, every
`paintTile` returns a buffer
in which every pixel is B=G=R=0, A=255 (opaque black). Writer documents in the
same process render
correctly (text on a white page). The same client on Linux, and on Windows with
25.2.7.2, renders
the same .xlsx correctly.
Independent of report 1: it happens with the formula bar hidden, and also with
the formula bar shown
when "VCL Main" is made an STA (the experiment in report 1) so that the
document loads.
Steps to reproduce:
1. Windows, LibreOffice 25.8.x or later; profile with
`/org.openoffice.Office.Views/Windows/26100`
`Visible` = false.
2. LOK: load an .xlsx, `initializeForRendering(doc, "")`, `paintTile(doc, buf,
256, 256, 0, 0, 3840, 3840)`.
3. Inspect `buf`.
Actual result: All 65536 pixels are (0, 0, 0, 255).
Expected result: The sheet's cells and text, as on Linux and as in 25.2.7.2.
Ruled out: the tile scale (256 px for 3840 and 12000 twips, 512 px for 3840
twips) and offset;
`setPart(0)`; `setClientVisibleArea` + `setClientZoom` before `paintTile`; the
renderer (default,
`SAL_DISABLESKIA=1`, `SAL_SKIA=raster`); colour configuration (Appearance =
Light, explicit
DocColor/AppBackground/FontColor). The machine reports no high-contrast mode.
Reproduced on a GitHub
Actions Windows runner and on a Windows 11 desktop.
Versions tested: 25.2.7.2 renders; 25.8.7.3, 26.2.7.1, 26.8.1.1 black.
Bibisect (https://bibisect.libreoffice.org/win64-25.8, 5412 builds from
2024-12-21 to
2025-12-10, 13 steps, each step the same LOK client and .xlsx):
last good build 90566ea3e (source 18e5d1ce26ab), first bad build e85ba78d5
(source
2507d08388dd). The range contains one source commit: 2507d08388dd "split the
SetSizeUsingBuffer
code paths" (Noel Grandin, 2025-01-16,
https://gerrit.libreoffice.org/c/core/+/180350).
That commit changes the default `SalVirtualDevice::SetSizeUsingBuffer()` in
`vcl/inc/salvd.hxx`
from `return SetSize(nNewDX, nNewDY);` to `assert(false && "unsupported");
return false;`, and
adds the split code paths only to the headless (`SvpSalVirtualDevice`) and Qt
backends.
`WinSalVirtualDevice` (`vcl/win/gdi/salvd.cxx`) does not override
`SetSizeUsingBuffer`, so on
Windows release builds the call now returns false and the tile device used for
Calc's tile
rendering is not set up. Possible fixes: restore the `SetSize` fallback in the
base class, or
implement `SetSizeUsingBuffer` in `WinSalVirtualDevice`.
Writer is unaffected in the same process, which suggests Calc's LOK tile path
is the one that
reaches `VirtualDevice::SetOutputSizePixelScaleOffsetAndLOKBuffer()` on
Windows.
--
You are receiving this mail because:
You are the assignee for the bug.
