Bug Hunting Session
Bug 55563 - FILEOPEN PPTX: 100% transparent image background shown semi transparent
Summary: FILEOPEN PPTX: 100% transparent image background shown semi transparent
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
4.0.0.0.alpha0+ Master
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: mab4.0
  Show dependency treegraph
 
Reported: 2012-10-03 05:19 UTC by Korrawit Pruegsanusak
Modified: 2013-02-17 06:21 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
screenshot (62.64 KB, image/png)
2012-10-03 05:19 UTC, Korrawit Pruegsanusak
Details
Screenshot of sample slide made with LOdev 3.7 (Master) 2012-10-27 on Mac OS X (413.21 KB, image/png)
2012-10-27 17:17 UTC, Roman Eisele
Details
Not reproducible here (45.10 KB, application/vnd.oasis.opendocument.presentation)
2012-12-11 18:52 UTC, Rainer Bielefeld Retired
Details
This one works for me (112.17 KB, application/vnd.openxmlformats-officedocument.presentationml.presentation)
2012-12-11 18:56 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Korrawit Pruegsanusak 2012-10-03 05:19:28 UTC
Created attachment 68022 [details]
screenshot

- Open attachment 46857 [details]

Expected:
- see attachment 46858 [details], without black border, of course!
- the image in top-right should not have a background

Actual:
- see screenshot attached
- the image in top-right have blue background, as indicated by arrows

Tested on Windows XP

NOT REPRODUCIBLE from W2008R2@20-With-Symbol-Bytemark-Hosting, pull time 2012-09-25 09:47:35, core: eebc9748d2ea26a7b5af246dba115103d6bb15db

REPRODUCIBLE from W2008R2@20-With-Symbol-Bytemark-Hosting, pull time 2012-09-26 20:38:48, core: 106a1b4eba1303e1d989eb67eff63ed864500578

Still REPRODUCIBLE from W2008R2@20-With-Symbol-Bytemark-Hosting, pull time 2012-10-01 05:02:30, core: e12f501bebf83ea8121e517283c25c24587268a7

So a recent regression in master.
Comment 1 Korrawit Pruegsanusak 2012-10-27 16:18:26 UTC
Still Reproducible on Windows XP with master pull time 2012-10-25_22.55.31.

NOT Reproducible on Linux

Git bisect and found that first bad commit is: http://cgit.freedesktop.org/libreoffice/core/commit/?id=f0efecfb69b336e064e7c8dd2597655eff07944f
Comment 2 Roman Eisele 2012-10-27 17:17:45 UTC
Created attachment 69157 [details]
Screenshot of sample slide made with LOdev 3.7 (Master) 2012-10-27 on Mac OS X



The attached screenshot, made with the LOdev 3.7 (master) build dated 2012-10-27 on Mac OS X 10.6.8 (Intel), shows that the bug is not reproducible on Mac OS X.
Comment 3 Michael Meeks 2012-10-29 10:27:39 UTC
Tibby - when bisected appears to come near your commit - any thoughts on this master regression ? :-)
Comment 4 Joel Madero 2012-11-03 17:41:38 UTC
I am unable to reproduce on Bodhi Linux with Master pulled two days ago.
Comment 5 Roman Eisele 2012-11-04 12:17:45 UTC
(In reply to comment #4)
> I am unable to reproduce on Bodhi Linux with Master pulled two days ago.

So all comments confirm that this bug appears on Windows only.
Anybody to confirm it (officially) on Windows?
Comment 6 Joel Madero 2012-12-11 16:38:52 UTC
Adding Rainer to this as I know he has a recent build on Windows.

Rainer can you test this out?
Comment 7 Rainer Bielefeld Retired 2012-12-11 18:50:06 UTC
1 Regression is enough

NOT Reproducible] with parallel installation of  "LOdev  4.0.0.0.beta1   -  GERMAN UI / German Locale  [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]"  {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch with a self created .pptx containing y .png with transparent bakcground area. Looks fine in edit mode and slide show.
Anti aliasing and hardware acceleration do not matter.

@Korrawit:
Can we get a sample document with brief comments concerning it's history?
You get the problem during the running slideshow or in edit mode or both?
Comment 8 Rainer Bielefeld Retired 2012-12-11 18:52:39 UTC
Created attachment 71352 [details]
Not reproducible here

@Korrawit:
Can you please test this .pptx (MSO2003) created with LibO 3.6.4.3? For me it works fine, right smiley shown without background, left smiley as expected with background.
Comment 9 Rainer Bielefeld Retired 2012-12-11 18:55:49 UTC
Comment on attachment 71352 [details]
Not reproducible here

Wrong document
Comment 10 Rainer Bielefeld Retired 2012-12-11 18:56:54 UTC
Created attachment 71353 [details]
This one works for me

Details see Comment 8!
Comment 11 Korrawit Pruegsanusak 2012-12-11 19:08:52 UTC
Rainer, Thanks for testing, but could you please test again with:

(In reply to comment #0)
> - Open attachment 46857 [details]

Thanks in advanced :)
Comment 12 Korrawit Pruegsanusak 2012-12-11 19:12:08 UTC
I just tested again with 4.0.0.0.beta1 on Windows 7 x64, and it's reproducible only in edit mode. Presentation mode: not reproduced.

I didn't check another version whether presentation mode affected. But with all tested and reproduced versions, it affects edit mode.
Comment 13 Korrawit Pruegsanusak 2012-12-11 19:13:22 UTC
(In reply to comment #12)
> I just tested again with 4.0.0.0.beta1 on Windows 7 x64, and it's
> reproducible only in edit mode. Presentation mode: not reproduced.

Sorry, I forgot to say that, this is for the file mentioned in comment 11.
Comment 14 Rainer Bielefeld Retired 2012-12-11 21:45:25 UTC
Where have I had my eyes?!
Works fine with "LibreOffice 3.6.4.3" German UI/ German Locale [Build-ID: 2ef5aff] {pull date 2012-11-28} on German WIN7 Home Premium (64bit).

[Reproducible] with parallel installation of  "LOdev  4.0.0.0.beta1   -  GERMAN UI / German Locale  [Build ID: 87906242e87d3ddb2ba9827818f2d1416d80cc7)]"  {tinderbox: @6, pull time 2012-12-06} on German WIN7 Home Premium (64bit) with separate /4 User Profile for Master Branch.

I see 2 Effects, 
a) the semi transparent background rectangles as shown in the screenshots
   in presentation edit mode
b) in Slideshow some "background colored St. Elmo's fire"

The picture itself seems ok? I extracted it after having saved the slideshow as .odp from 3.6.4 and 4.0, no difference, works fine, also when I import the pictures into the sample. But stop, the problem also disappears when I save the sample document from LibO 3.6.4 AND when I save it from LibO 4.0 as .odp. This causes very bad other problems, but the picture background disappears.

Compression problem or similar? I will have to think about that tomorrow.
Comment 15 Rainer Bielefeld Retired 2012-12-13 15:57:41 UTC
I hoped in vain to find some relations or similar. We had some other picture problems with MS XML document import, but this one seems different to any other problem I find or remember.
Comment 16 Michael Meeks 2012-12-17 20:16:55 UTC
I don't see this with master for the 1st document; it's unclear what the 2nd (comment #10 Rainer?) is supposed to show. I see two smileys, one in a white rectangle, one without (identical to 3.6.x). I'm using a build from:

bb3f2900a867fdcb6df916fff58199b4ce94dd05
Comment 17 Rainer Bielefeld Retired 2012-12-17 21:33:03 UTC
Comment on attachment 71353 [details]
This one works for me

Sorry, this attachment has nothing to do with the bug, i simply did not see
 - Open attachment 46857 [details]
in the original report-

@Michael:
Sorry, may be I mislead you to do the same mistake?
Comment 18 Michael Meeks 2012-12-18 10:33:58 UTC
Korrawit - thanks for the bisection: can you still reproduce with a recent 4.0 or master build ? Noel this was kindly bisected by Korrawit to near your commit - any thoughts ?
Comment 19 Noel Power 2012-12-18 11:54:17 UTC
(In reply to comment #18)
> Korrawit - thanks for the bisection: can you still reproduce with a recent
> 4.0 or master build ? Noel this was kindly bisected by Korrawit to near your
> commit - any thoughts ?

no idea, if it is the commit identified in comment #1 then indeed I am the comitter but not the author see comment #3

if indeed it is that commit then strange that this is windows specific :-/ Also that patch doesn't tweak the transparency ( but the shadow transparency )

I had a windows build ( dated 2012-12-13 ) and I still see this problem present with it so it appears to be still an issue. Also noticed if the transparency is changed e.g. to select 50% ( and then changed back again to no transparency ) then the bad effect is gone. Perhaps there is some strange property setting order ( or timing related ) issue that only rears it's head on windows. No idea though still if the commit above really does trigger this or not ( that patch itself though looks ok )
Comment 20 Noel Power 2012-12-18 13:06:41 UTC
ok firstly it is the patch that causes the problem, it appears that it really is the shadow transparency that affects things. But also the shadow transparency value imported is good. It seems that how that shadow is applied to the shape is somehow broken on windows. No idea about that stuff I'm afraid, not sure who would know maybe radek?
Comment 21 Noel Power 2012-12-18 13:07:48 UTC
(In reply to comment #20)
> ok firstly it is the patch that causes the problem, it appears that it
> really is the shadow transparency that affects things. But also the shadow
> transparency value imported is good. It seems that how that shadow is
> applied to the shape is somehow broken on windows. No idea about that stuff
> I'm afraid, not sure who would know maybe radek?

and also worth noting that on 3.6 this doesn't seem to be a problem ( I had a 3.6 windows build and applied the patch, don't see the same nasty effect when changing shadow transparency )
Comment 22 Michael Meeks 2012-12-18 14:21:23 UTC
+ rPropMap.setProperty( PROP_ShadowColor, maShadow.moShadowColor.getColor(rGraphicHelper, -1 ) );
+ rPropMap.setProperty( PROP_ShadowTransparence, maShadow.moShadowColor.getTransparency());
etc.

all get shoved into a:

 typedef ::std::map< sal_Int32, ::com::sun::star::uno::Any > PropertyMapBase;

I wonder if some iteration order for that is different between the win32 std::map and everyone else's (somehow).
Comment 23 Noel Power 2012-12-18 15:03:47 UTC
(In reply to comment #22)
> + rPropMap.setProperty( PROP_ShadowColor,
> maShadow.moShadowColor.getColor(rGraphicHelper, -1 ) );
> + rPropMap.setProperty( PROP_ShadowTransparence,
> maShadow.moShadowColor.getTransparency());
> etc.
> 
> all get shoved into a:
> 
>  typedef ::std::map< sal_Int32, ::com::sun::star::uno::Any > PropertyMapBase;
> 
> I wonder if some iteration order for that is different between the win32
> std::map and everyone else's (somehow).

nah, don't think so, like I said changing the shadow transparency manually with the test document and you get the strange effect ( I was confused previously by changing the normal shape transparency which has the side effect of clearing the shadow transparency which in turn makes gets rid of the strange background border effect )
Comment 24 Jorendc 2012-12-26 17:22:34 UTC
*** Bug 58782 has been marked as a duplicate of this bug. ***
Comment 25 Korrawit Pruegsanusak 2013-02-17 06:21:48 UTC
Sorry for very late reply :(

This bug disappeared since http://cgit.freedesktop.org/libreoffice/core/commit/?id=edf54efa7f939be9b289f94ed4f19fb8322660ef (in branch -4-0)

commit edf54efa7f939be9b289f94ed4f19fb8322660ef
Author: Michael Stahl <mstahl@redhat.com>
Date:   Fri Dec 21 13:54:43 2012 +0100

    fdo#55044: OutputDevice::ImplDrawAlpha:

    reset members before calling GetBitmap(), as apparently they are used by
    GetBitmap(), resulting in missing/not rendering parts of the preview
    image in the bugdoc.

    (regression from c0ce7ca4884f7f6d1016bd1dbcc22066cb4a7797)

    Change-Id: I02a6abb822900e1a28a1c632a122c1e093b73553
    (cherry picked from commit 06968a96afd334c276b425bf6b809c011f88b716)

But I don't know how the fix also affects this bug. Marking as RESOLVED/WORKSFORME