Bug 90079 - Images in particular document render all black on OSX at certain zoom levels
Summary: Images in particular document render all black on OSX at certain zoom levels
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: Other macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Regressions-GraphicPrimitive2D
  Show dependency treegraph
 
Reported: 2015-03-18 04:48 UTC by Matthew Francis
Modified: 2022-02-21 09:22 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2015-03-18 04:48:25 UTC
Reproduced on OSX 10.10, LibreOffice 4.2.0.4 and later (4.1.6.2 and earlier are not affected)

The images contained in attachment 113502 [details] of bug 89473 render as all black at zoom levels greater than around 65%. This does not appear to occur on Linux.

These two bugs both relate to all-black images, so they are probably related in some way (some characteristic of the images?), but they begin at completely different points in history.
Comment 1 Alex Thurgood 2015-03-18 10:21:51 UTC
Confirmed on master 

Version: 4.5.0.0.alpha0+
Build ID: 93b0b5b71dc1251ea2f1873b42b2e5f82bf9d9e4
Locale: fr_

OSX 10.10.2

where the images are black at document magnification above 90%
Comment 2 Matthew Francis 2015-04-10 16:56:51 UTC
OSX bibisect points to a very small range in which the below looks like the only possible candidate. Exactly why this would only affect OSX is unclear.

commit 2e5167528f7566dd9b000e50fc1610b7bf99132a
Author:     Armin Le Grand <alg@apache.org>
AuthorDate: Thu Oct 31 14:43:21 2013 +0000
Commit:     Caolán McNamara <caolanm@redhat.com>
CommitDate: Tue Nov 5 15:24:18 2013 +0000

    Resolves: #i123500# unified Graphic processing to use GraphicPrimitive2D
    
    (cherry picked from commit f5d69b2b8b002ca6905496a9d9065ef76b5641d7)
    
    Conflicts:
        sw/source/core/doc/notxtfrm.cxx
    
    Change-Id: I1758aadcbe97ece271277378e62300b895421768
Comment 3 Robinson Tryon (qubit) 2015-12-13 11:12:14 UTC Comment hidden (obsolete)
Comment 4 Xisco Faulí 2016-09-26 15:03:17 UTC
Adding Cc: to Armin Le Grand
Comment 5 Alex Thurgood 2017-07-31 08:35:30 UTC
Bug still present in 

Version: 5.3.4.2
Build ID: f82d347ccc0be322489bf7da61d7e4ad13fe2ff3
Threads CPU : 4; Version de l'OS :Mac OS X 10.12.6; UI Render : par défaut; Moteur de mise en page : nouveau; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group
Comment 6 Alex Thurgood 2017-07-31 08:37:04 UTC
Also still present in 

Version: 6.0.0.0.alpha0+
Build ID: 376e27dd498d64212e570354a94c527b37d367b1
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Comment 7 QA Administrators 2019-03-02 03:51:08 UTC Comment hidden (obsolete)
Comment 8 eisa01 2020-03-28 10:01:21 UTC
Still there

Version: 7.0.0.0.alpha0+
Build ID: 0cb4f304abf6f8dd6b40eb800788d2fe80581813
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 9 Armin Le Grand 2021-12-15 10:47:59 UTC
Checked f5d69b2b8b002ca6905496a9d9065ef76b5641d7, that just unifies handling. The same graphic gets painted in the backend. I see nothing mac specific. Unfortunately I have no access to a mac, but probably is something in the graphics backend that gets slightly triggered different. That it's not in the common part is pretty safe to say since it works elsewhere
Comment 10 Armin Le Grand 2022-02-21 09:22:13 UTC
I have no mac, so have to restrain