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
Re: [sugar] video bleeds through somewhat between sessions
Jordan Crouse writes: > 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. That should have gone out of style with those ISA VGA cards that had a ribbon connector on top to accept video from a tuner card. The hack almost made sense with a palette. If a 32-bit framebuffer were used, would the use of the top 8 bits fix this problem? (valid colors are 0 to 0xff, so use 0x100) > 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. Better would be 0xff00fe or 0xfe00ff, appropriately adjusted to deal with 16-bit color. (0xf81e or 0xf01f I think) Decrement either the red value or blue value to avoid being perfect magenta. > Nothing to worry about - just a fun little side effect of video > acceleration. Well, it does detract from the overall appearance. ___ 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
> > > 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
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
>> 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. I think you and I are agreed on the undesirability of having the video affect what is currently shown on the XO screen, when the user has caused what is now being shown on that screen to be taken from a 'session' other than the 'session' containing the video application. But the video *application* typically does not know if the user is looking at its "output screen", or not. At best, the operating system which lets the user __switch__ to a different 'session', could send a "signal" to the transferred_away_from session -- but even if told, does the video *application* support changing its video output ? I'm thinking of the example provided by the X-window system -- when one (non-transparent) window has the focus, it somehow PREVENTS having users see the content of whatever is "behind". Maybe the facility used to draw XO screens can similarly PREVENT having users see any content of whatever 'sessions' are NOT being shown. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] video bleeds through somewhat between sessions
On Tue, Aug 5, 2008 at 9:21 AM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > But the video *application* typically does not know if the user is There are signals that the wm will send to indicate "you're the foreground window", "you've lost your focus", "you're minimized". 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. Though I have to say I don't know a thing about how Sugar deals with such wm signals. 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
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 Wed, 2008-08-06 at 01:43 -0400, Benjamin M. Schwartz 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. 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? There is no blitting going on The video unit takes the yuv data, scales it, and puts it where you tell it to. The color key determines if it is visible. - Jim -- Jim Gettys <[EMAIL PROTECTED]> One Laptop Per Child ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
