[Bug 10160] EXA on r300 with merged framebuffer is slow and fails to repaint XV colorkey properly

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=10160





------- Comment #1 from agd5f at yahoo.com  2007-03-02 08:49 PST -------
(In reply to comment #0)
> I noticed this, when running totem under an EXA "accelerated" environment. This
> is a cut and paste from the gnome bugzilla, where I fist suspected xvimagesink
> of gestreamer to be the cause of the bug:
> 
> "Totem is currently unusable for me, when running a setup with EXA and the
> composite extension enabled, becaus everytime somethink covers the totem
> window, the video is hidden in that part. Problem is, that for example gaim
> causes this effekt for the whole desktop when hiding the gaim window.
> 
> Testing with xine and mplayer (both also using the XV extension) don't show
> this effect.
> 

Then what makes you think this is a driver bug? if these other Xv apps work
fine, wouldn't that indicate totem is to blame?  Are you using autopaint for
the colorkey or is the app doing it?  Also with composite, make sure the colors
are actually the same and not a composited color because the overlay will only
paint on the color of the key. 

> Steps to reproduce:
> 1. run a xserver with EXA and Composite Extension
> 2. gst-launch-0.10 videotestsrc ! xvimagesink
> 3. move anoterh window over the window of the xvimagesink and move this window
> away
> 4. move xvimagesink
> 

I'm not quite sure I follow.

> 
> Actual results:
> on step 3. the part of the xvimagesink window, that was hidden by the other
> window is not redrawn with the contents of the videotestsource. Moving the
> window make the contents visible again/completly
> 
> Expected results:
> in step 3. the xvimageink window should be completly refreshed
> 
> Does this happen every time?
> yes"
> 
> Basicly I just get parts of the unterlying window/desktop shown in the video
> window, when the covering window is removed from the xvimagesink window.
> 
> So after a reply from Jan Schmidt I tested again and ran without merged
> framebuffer enabled. There I noticed two things:
> 
> 1. The gstreamer bug was gone
> 2. The system felt much better
> 
> 2. means, that when running with merged framebuffer (at max. 3080x1050) I had
> to run xcompmgr, to get an evnvironment, I could work in, this was not
> necessary in the 1680x1050 case without merged framebuffer.
> 

Of course everything is going to be much slower at 3080x1050!  You've doubled
the size of an already big the desktop.  These chips only have so much
bandwidth available.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.