Bug 136245 - Page count is terribly off on file open with a large table; ultimately it will work (but seems slower). Fine in 6.0 (Windows Only)
Summary: Page count is terribly off on file open with a large table; ultimately it wil...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1 all versions
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, possibleRegression
Depends on:
Blocks: Fields-Page-Count
  Show dependency tree / graph
 
Reported: 2020-08-28 21:19 UTC by Telesto
Modified: 2022-01-24 11:45 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-08-28 21:19:00 UTC 
Description:
Page count is terribly off on file open with a large table; ultimately it will work (but seems slower)

Steps to Reproduce:
1. Open attachment 107266 [details] (bug 84635)
2. Wait until the document appears
3. look at the page count - 43 
4. Wait rather long time -> Drops to 26 (expected)


Actual Results:
Opens with 43 pages

Expected Results:
26 pages straight forward, not first 43 and trimming down to 26


Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 7.1.0.0.alpha0+ (x64)
Build ID: 6640d7f405d2970ba2825a9455926cc803284d01
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

and in
6.2

also in (opening fast, but number of spurious pages on file open (not being trimmed down). Exactly: 43 pages
6.1 

fine with 
6.0
Comment 1 Telesto 2020-08-29 20:44:49 UTC 
My bibisect attempt lands here. 
author	Jan-Marek Glogowski <glogow@fbihome.de>	2018-07-09 09:06:55 +0200
committer	Khaled Hosny <khaledhosny@eglug.org>	2018-07-09 22:11:35 +0200
commit fad862e290d727fc9fefe206f6e4b807482c4175 (patch)
tree 5195c1277fce198e5b69d552e9209665d8007faf
parent 9d754a59154c40235c240bb0e7f47a2006fa85bd (diff)
tdf#118555 fix HFONT fallback handing / lifecycle
Instead of storing the never changing DC in the WinFontInstance
store the HFONT, which is Windows logical font instance.

Then set the correct HFONT instance from the layout when rendering
its text.

This also changes the HFONT ownership and lifecycle. The HFONT
is moved from the mhFonts to the WinFontInstance, if available,
so it has a proper referenced lifecycle. The mhFonts is still
needed, as embedded font just supply an HFONT and no
WinFontInstance.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=fad862e290d727fc9fefe206f6e4b807482c4175

However coming without warranties, as there is also sorts of quirky behavior in the 6.2 bibisect repro.
Note 2: The 43 to 26 is also in 6.1, but is simply fast disappearing. So maybe i'm looking in the wrong bibisect repro?
Comment 2 Telesto 2020-08-29 20:47:30 UTC 
@Buovjaga,
4 eyes so more than 2.. Any idea how to approach this?
Comment 3 Buovjaga 2020-08-30 12:20:06 UTC 
(In reply to Telesto from comment #0)
> Description:
> Page count is terribly off on file open with a large table; ultimately it
> will work (but seems slower)
> 
> Steps to Reproduce:
> 1. Open attachment 107266 [details] (bug 84635)
> 2. Wait until the document appears
> 3. look at the page count - 43 
> 4. Wait rather long time -> Drops to 26 (expected)

Goes from 41 to 26, took maybe 10 secs.

Version: 7.1.0.0.alpha0+ (x64)
Build ID: a486fd929d4b3e915f928ef495b6cb2b96d74a3a
CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: default; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded