Bug 5558 – flashing pixels around the lock button if media player is playing a video.

Bug 5558 - flashing pixels around the lock button if media player is playing a video.


Summary:	flashing pixels around the lock button if media player is playing a video.

Status:	RESOLVED FIXED

Product:	Media player
Component:	General
Version:	5.0/(1.2009.42-11)
Platform:	N900 Maemo

Importance:	Low minor (vote)
Target Milestone:	5.0/(2.2009.51-1)
Assigned To:	unassigned
QA Contact:	media-player-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2009-10-17 22:51 UTC by Bernard Schendstok
Modified:	2010-01-14 12:27 UTC (History)
CC List:	7 users (show)

See Also:

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 Bernard Schendstok (reporter) 2009-10-17 22:51:25 UTC

SOFTWARE VERSION:
1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:
play a video file in the media player and lock the device. Then when you press
the on/off switch briefly, you get the unlock screen.

EXPECTED OUTCOME:
you would except to see the normal unlock screen

ACTUAL OUTCOME:
Around the unlock slider there are flashing pixels (probably from the movie in
the background)

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.14)
Gecko/2009090216 Linux Mint/6 (Felicia) Firefox/3.0.14

Comment 1 Lucas Maneos 2009-10-18 19:36:14 UTC

Could reproduce as follows:

1. Start video playback.
2. Lock device by pressing the power button and selecting "Secure device".
3. Observe video artifacts on the "Enter lock code" title bar and input field.
4. Lock screen with the right-hand side switch.
5. Press power button to get the "Swipe to unlock" screen.
6. Video artifacts visible around the on-screen slider widget.

Doesn't sound like a media player bug, but I don't know what the right
component would be.  Maybe the compositing manager (is that hildon-desktop?) or
X server?

Comment 2 Alexander Bokovoy 2009-10-19 07:24:20 UTC

I can easily reproduce this by starting video and calling for "lock device"
dialog. 

This is known issue with xvideo and colorkey. 

XVideo has 1-bit transparency support and uses colorkey to separate what is
shown on the screen and from what plane it comes in our display subsystem --
1-bit implicit mask is used to specify which pixels come from graphics plane
(UI) and which are coming from video plane, the ones that have colorkey are
representing this mask.

It looks like unlock screen simply does not do anything for colorkey (it didn't
know about it) and thus existing mask (set by and used for MediaPlayer) is in
action.

Ideally, MediaPlayer would need to use magenta colorkey to ensure that it is
not present in any UI parts (magenta is an imaginary color that is not present
in real life). This was discussed multiple times for camera and MediaPlayer,
though I do not know current outcome in MediaPlayer case.

Felipe Contreras should be the best person who knows about this issue very
well.

Comment 3 Lucas Maneos 2009-10-20 04:07:26 UTC

Felipe: ping, any comments you may have appreciated.

Comment 4 Felipe Contreras nokia

2009-11-17 12:15:53 UTC

Oops, I forgot to reply. Yes, this is a known bug an IMO a first good step
would be to make the UI color-key independent so that we can use a color that's
not used in the theme.

There's a proposal for a generic GTK+ widget that implement this, but
apparently there are a few issues. I think the plan was to make this bug public
so that the community can help maybe finding some workarounds.

Comment 5 Andre Klapper maemo.org

2009-11-19 17:05:14 UTC

This definitely seems to be fixed in 2.2009.47-18 (I remember an internal meta
bug about any screen noise and all sub-bugs were fixed in week 46).
I've tried a few times and cannot reproduce it.

Comment 6 Lucas Maneos 2009-11-24 09:05:04 UTC

*** Bug 6304 has been marked as a duplicate of this bug. ***

Comment 7 Lucas Maneos 2009-12-12 13:29:52 UTC

*** Bug 6803 has been marked as a duplicate of this bug. ***

Comment 8 Andre Klapper maemo.org

2010-01-14 12:27:00 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.