Re: [sugar] rendering test
On 28/09/08 18:46 +0200, Bernie Innocenti wrote: Tomeu Vizoso wrote: Ooops. cc'ing to some other people/list in the hope someone more knowledgeable than me will comment. Thanks. Please Cc me on posts like these to make sure I don't miss them. No, it doesn't bother me to receive 0.001% more mail. I've also Cc'd the Xorg list in case someone can give us more insight. On Sun, Sep 28, 2008 at 12:46 PM, Riccardo Lucchese [EMAIL PROTECTED] wrote: On Sun, 2008-09-28 at 12:43 +0200, Riccardo Lucchese wrote: * build 703, xorg driver = amd, redraws = 200 - pixbuf: 98.63s 96.96s 96.58s 97.14s 99.21s * build 703, xorg driver = fbdev, redraws = 200 - pixbuf: 55.81s 55.40s 55.22s 55.50s 55.63s * build 2489, xorg driver = amd, redraws = 200 - pixbuf: 84.21s 84.81s 81.94s 81.79s 85.29s * build 2489, xorg driver = fbdev, redraws = 200 - pixbuf: 62.83s 62.81s 62.81s 62.66s 63.14s - joyride regressed sensibly at rendering with cairo since 703 - rendering pixbufs is extremely slow on the xo - server side surfaces are awesome ;) and btw why is fbdev faster than the geode driver at rendering pixbufs ? Was fbdev running with EXA or XAA? (does fbdev even support EXA?) My performance tests with X 1.3 and 1.4 had shown that turning on EXA makes many operations slower. It's hard to tell why, but it might have to do with loosing XShmPut() (MIT shared memory), excessive migration of pixmaps to the framebuffer, and so on. X 1.5 was supposed to have a much better EXA, at least judging from the stream of patches landed on the tree. Indeed - migration is probably what is hurting us the most here. We would probably have to do a more in-depth analysis of what is actually happening in the engine, but the general rule of thumb is that it is very very very very very bad to read from the video memory. Jordan (Did I mention it was bad?) -- 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
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
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
