Re: [sugar] video bleeds through somewhat between sessions
Quoting Martin Langhoff [EMAIL PROTECTED]: There is probably a bug in the mplayer wrapper (are you using an mplayer 'activity' wrapper?) in that it's not getting rid of the overlay setup when it loses focus or is minimized. This is not a bug, at least in the case of losing focus. Color-keyed video acceleration is designed specifically for the case of playing video in a background window that is partially obscured by a window in front of it. This works correctly so long as the chosen key color isn't present in the foreground window, and so the favored key color is hot pink because it is so rarely used. The problem here appears to be that mplayer has chosen a key color that is a shade of gray. That's a poor choice, and arguably a bug. However, Mikus has a good point here. Insofar as XVideo's color keying is designed to overlap windows correctly with live video, it is unnecessary in our single-window UI. The GPU is doing a great deal of unnecessary work to blit a video that we already know to be completely occluded. Minimizing Activity windows might be a good way to start fixing this. We should also consider what happens when two running Activities both want to use XVideo. Can we multiplex access to XVideo, knowing that only one Activity is ever actually visible at a time? --Ben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
On Wed, Aug 6, 2008 at 5:43 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: Quoting Martin Langhoff [EMAIL PROTECTED]: There is probably a bug in the mplayer wrapper (are you using an mplayer 'activity' wrapper?) in that it's not getting rid of the overlay setup when it loses focus or is minimized. This is not a bug, at least in the case of losing focus. The mplayer activity - as it's running on Sugar, should know that there are not overlapping windows here. I am not sure what event the vm is sending when the app loses foreground but a sugar app should stop the overlay, move it off-viewable screen, etc. it is unnecessary in our single-window UI. Exactly, it is pointlless work. The activity can perhaps stop playing, and resume when the user returns, with the appropriate time offset, hiding from the user that it stopped playing the video. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
On 02/08/08 18:53 -0400, Mikus Grinbergs wrote: It is the video chip's feature that it can display a video overlay over the RGB bitmap. The pixels where the overlay can be seen is defined by a colorkey (what was 0xFF00FF in the example), or the alpha component of the display RGB bitmap (not used on the XO since the change 16 bit bitmaps). What you are seeing that the X server does not disable the video overlay while switching programs. It can be an error or just some braindamaged X stuff. Either way, it has nothing to do with bitmap operations. Then I believe there *was* something wrong: When I was looking at the character-based Terminal screen, there should not have been a 'video overlay' interacting with what was being shown to me. When I am looking at the (full-screen) video output, if what I see involves a 'video overlay' -- that's fine with me. But when I switch away from the 'session' displaying the video output, I don't want interference to what I'm currently looking at (whether that interference comes from a 'video overlay', or from whatever). Then the video application needs to stop the video or change the demensions of the overlay window. The hardware is only doing what it is told to do. Both persons who have answered me have talked about how things from the video frame can be seen. But I was not looking at video - I was looking at TEXT. If I understand correctly what has been told me here, neither the 'black' of the text characters themselves, nor the 'white' of the background for the text, should have _allowed_ things from the video frame to be seen. I definitely did not see any color. What I did see was that some parts of the 'black' text characters changed briefly to _less_ 'black' (they went black -- gray -- black) depending on where on *its* screen the ongoing video 'session' WOULD HAVE depicted bright or dark areas. Right - you were looking at text, which is not actually black and white in sugar - it is antialiased (http://en.wikipedia.org/wiki/Antialiasing). The font renderer is antialiasing the text, so that there are numerous shades of grey pixels surrounding the glyphs. These will match the color key, and will refelect the video behind it, but since you are only seeing a few pixels surrounding the text, there isn't enough context to see the video from behind, but there is enough contrast for your eye to notice the difference. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
Both persons who have answered me have talked about how things from the video frame can be seen. But I was not looking at video - I was looking at TEXT. If I understand correctly what has been told me here, neither the 'black' of the text characters themselves, nor the 'white' of the background for the text, should have _allowed_ things from the video frame to be seen. I definitely did not see any color. What I did see was that some parts of the 'black' text characters changed briefly to _less_ 'black' (they went black -- gray -- black) depending on where on *its* screen the ongoing video 'session' WOULD HAVE depicted bright or dark areas. I think that the operating theory is that, around the edges of the black text, there are some pixels which are grey (or even, because of the funny xo color magic, colored?). These pixels would then be transparent. Is this consistent with your experience? In other words, is it possible that the video was fully visible in occasional pixels, instead of partially visible in all the black text pixels? ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
G1G1, Joyride 2241. In one Terminal session started mplayer -- it was playing a movie. Went to another Terminal session, and entered some commands. Noticed that not all of the text on that screen was equally distinct - some of it was paler than others. Noticed that *which* text was paler changed from second to second. Realized that the paler text in the second Terminal screen corresponded to the *brightest* areas of the movie frame then being shown in the first Terminal screen (the one I had switched way from). Video is muxed to the visible screen through the use of a color key - given a rectangle of some size, the hardware compares all of the pixels in that rectangle against a set color - if they match, then a pixel of the video frame is shown, otherwise not. The color is specified by the video application - most applications use very saturated colors similar to those used in green or blue screens. My favorite is hot pink (0xFF00FF). IIRC, mplayer uses an off-shade color of grey, so it is easier to run into the possibility that other applications will match the color key, especially with automatic shading such as anti-aliasing. I did NOT understand at all what you are trying to say. [I used the words in the subject line to try to describe that what *would* have been shown by one program (whose output window I was NOT looking at) bled through to affect what *was* being shown from ANOTHER program (whose output window I WAS looking at).] In my mind, a 'session' can request that certain pixels be displayed on the screen. [If a text-output program is running, it will request pixels which make up an image of a text character. If a video-output program is running, it might request pixels which make up an image of a white cloud.] My point is that each program (that is, 'session') supplies __its own__ set of rendering requests. I would expect that if I am looking at an area of the display which I thought was dedicated to output from program A, then I will ONLY see pixels as requested by program A (no muxing!). What was happening to me was: while looking at the screen showing output from program A (Terminal 'session'), the pixels themselves (i.e., for black text characters) appeared to have been requested by program A. But the intensity of those pixels (how black they were) appeared to be MODIFIED by whatever intensity program B (mplayer 'session') wanted for that spot on the screen. Since it is the driver interface (or something) software that ACCEPTS the pixel-rendering requests issued by the running programs, I would expect that when I switch away from session B, the rendering requests still bing issued by session B would be IGNORED in their entirety (until B again has the focus). Why should the video have to be 'muxed' from the simultaneous output of multiple sessions ? Why, when session A has the focus, should anything done by session B affect HOW A's output gets shown ? mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
It is the video chip's feature that it can display a video overlay over the RGB bitmap. The pixels where the overlay can be seen is defined by a colorkey (what was 0xFF00FF in the example), or the alpha component of the display RGB bitmap (not used on the XO since the change 16 bit bitmaps). What you are seeing that the X server does not disable the video overlay while switching programs. It can be an error or just some braindamaged X stuff. Either way, it has nothing to do with bitmap operations. Then I believe there *was* something wrong: When I was looking at the character-based Terminal screen, there should not have been a 'video overlay' interacting with what was being shown to me. When I am looking at the (full-screen) video output, if what I see involves a 'video overlay' -- that's fine with me. But when I switch away from the 'session' displaying the video output, I don't want interference to what I'm currently looking at (whether that interference comes from a 'video overlay', or from whatever). Both persons who have answered me have talked about how things from the video frame can be seen. But I was not looking at video - I was looking at TEXT. If I understand correctly what has been told me here, neither the 'black' of the text characters themselves, nor the 'white' of the background for the text, should have _allowed_ things from the video frame to be seen. I definitely did not see any color. What I did see was that some parts of the 'black' text characters changed briefly to _less_ 'black' (they went black -- gray -- black) depending on where on *its* screen the ongoing video 'session' WOULD HAVE depicted bright or dark areas. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
On 01/08/08 15:00 -0400, Mikus Grinbergs wrote: G1G1, Joyride 2241. In one Terminal session started mplayer -- it was playing a movie. Went to another Terminal session, and entered some commands. Noticed that not all of the text on that screen was equally distinct - some of it was paler than others. Noticed that *which* text was paler changed from second to second. Realized that the paler text in the second Terminal screen corresponded to the *brightest* areas of the movie frame then being shown in the first Terminal screen (the one I had switched way from). Video is muxed to the visible screen through the use of a color key - given a rectangle of some size, the hardware compares all of the pixels in that rectangle against a set color - if they match, then a pixel of the video frame is shown, otherwise not. The color is specified by the video application - most applications use very saturated colors similar to those used in green or blue screens. My favorite is hot pink (0xFF00FF). IIRC, mplayer uses an off-shade color of grey, so it is easier to run into the possibility that other applications will match the color key, especially with automatic shading such as anti-aliasing. Nothing to worry about - just a fun little side effect of video acceleration. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
