Download it now!
Bug 116213 - OS X and OpenGL bitmap scanline sizes are not 32-bit aligned
Summary: OS X and OpenGL bitmap scanline sizes are not 32-bit aligned
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 116484 116551 (view as bug list)
Depends on:
Blocks: OpenGL Images
  Show dependency treegraph
 
Reported: 2018-03-05 18:00 UTC by Chris Sherlock
Modified: 2019-12-18 21:31 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Splash screen (28.35 KB, image/png)
2018-03-19 04:05 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Sherlock 2018-03-05 18:00:20 UTC
Description:
Windows bitmap must be 32-bit aligned (cf http://www.fileformat.info/format/bmp/egff.htm - “Pixels are packed into bytes and arranged as scan lines. Each scan line must end on a 4-byte boundary, so one, two, or three bytes of padding may follow each scan line.”).

Our OpenGL and OS X implementations don’t honour this (see https://opengrok.libreoffice.org/xref/core/vcl/opengl/salbmp.cxx#772 and https://opengrok.libreoffice.org/xref/core/vcl/quartz/salbmp.cxx#317).

In fact, our test code notes this also - see https://opengrok.libreoffice.org/xref/core/vcl/qa/cppunit/BitmapTest.cxx#334

I’m logging this as a bug I’ll need to fix when I get back from holidays.

Steps to Reproduce:
n/a

Actual Results:  
n/a

Expected Results:
n/a


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (iPad; CPU OS 11_2_6 like Mac OS X) AppleWebKit/604.1.34 (KHTML, like Gecko) CriOS/64.0.3282.112 Mobile/15D100 Safari/604.1
Comment 1 V Stuart Foote 2018-03-05 19:19:45 UTC
Good luck with it Chris, let us know if it needs testing...
Comment 2 Chris Sherlock 2018-03-05 23:36:28 UTC
I’ll add some unit tests, the only user testing is to insert some bitmaps into documents on OS X systems, and systems that use OpenGL. But it’s largely something that is not user visible.
Comment 3 Chris Sherlock 2018-03-13 14:25:19 UTC
Proposed patch is now on gerrit:

https://gerrit.libreoffice.org/#/c/51222/
Comment 4 Commit Notification 2018-03-16 08:52:32 UTC
Chris Sherlock committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=460f39e687393b3a8906d2adc3e8f7a0c749851a

tdf#116213 OS X and OpenGL bitmap scaline sizes are not 32-bit aligned

It will be available in 6.1.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.
Comment 5 Chris Sherlock 2018-03-16 20:22:59 UTC
For QA: I opened a number of PNG images, including a 7x3 PNG, to see if everything worked alright, also checked toolbars and other UI elements.
Comment 6 Aron Budea 2018-03-19 04:05:27 UTC
Created attachment 140699 [details]
Splash screen

This is what the splash screen looks like for me in a recent master build (e08e6516a01f28f2dd2581e3326be6d6b6eddb55) / Windows 7, with OpenGL enabled. Some toolbar icons, and the document previews in the start center are also messed up.

Reverting 460f39e687393b3a8906d2adc3e8f7a0c749851a fixes this issue for me.
Comment 7 Luke 2018-03-19 16:35:28 UTC
On both my Nvidia gtx 650 and Intel HD 5000, all bitmaps are corrupted. See Bug 116484 for a test document.
Comment 8 Commit Notification 2018-03-21 14:16:41 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ebe247642d85d39b6e1ffae3cf92c31748f2e983

Revert "tdf#116213 OS X and OpenGL bitmap scaline sizes are not 32-bit aligned"

It will be available in 6.1.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.
Comment 9 Xisco Faulí 2018-03-21 16:56:01 UTC
*** Bug 116484 has been marked as a duplicate of this bug. ***
Comment 10 Xisco Faulí 2018-03-21 16:57:04 UTC
Since the commit has been reverted, I'm closing bug 116484 as a duplicate of this one.

@Chris, If you submit a new patch, please make sure bug 116484 isn't introduced again...
Comment 11 Aron Budea 2018-03-21 21:46:08 UTC
*** Bug 116551 has been marked as a duplicate of this bug. ***
Comment 12 Stefan_Lange_KA@T-Online.de 2018-03-22 03:44:38 UTC
I have tested with
 
Version: 6.1.0.0.alpha0+ (x64)
Build ID: 751191ed2d7d6af6eddc3d738e8c45b0a2ab2572
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-22_00:36:35
Locale: de-DE (de_DE); Calc: CL

and using OpenGL for all rendering all test cases described in Bug 116551: 
Problem did not occur! All pictures were displayed correctly.
Comment 13 Chris Sherlock 2018-03-25 21:06:39 UTC
Thanks folks, I tested in debug mode on OS X, it appears this is why things weren’t picked up.

Of course, don’t understand the comment “And why would fixing tdf#116213 for Windows require touching the macOS-specific code, anyway?” - not sure what this means, given Windows bitmap padding isn’t a bug, it’s part of the Bitmap specification.
Comment 14 Xisco Faulí 2018-06-25 09:16:43 UTC
Dear Chris Sherlock,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 15 QA Administrators 2019-06-26 02:47:03 UTC Comment hidden (obsolete)
Comment 16 Luke 2019-07-27 23:18:47 UTC
Chris,
Polite ping. What is the status of this issue?
Comment 17 Chris Sherlock 2019-12-18 21:31:53 UTC
Let's leave this one.