video bleeds through somewhat between sessions

[NoiseEHC]

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.

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.
>>     
>
> 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
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
>
>