severity 412080 wishlist thanks On Mon, Feb 26, 2007 at 11:09:06AM +0100, Diego Biurrun wrote: > > Please don't close. Your refusal to fix it is already reflected by the > > wontfix tag; closing it is not necessary and is a bad thing since it'll > > hide the discussion (which at the least will be useful for reference). > > So wontfix bugs will stay open forever? This does not make sense to > me..
Yes. That's the point of archiving discussion, that it can be checked at any time. Bug reports should be closed when fixed. If you don't intend to fix it (as the wontfix tag shows), then it should not be closed. Though, I acknowledge that this is a wishlist item rather than a bug as-is. > > It was my understanding that hardware scaling is necessary for _slow_ > > machines, not fast ones. But you seem to contradict that. Please can > > you explain? > > Hardware scaling is not for slow machines. Hardware scaling is simply > the faster way to scale. Not supporting hardware scaling amounts to not > having fullscreen playback on moderately fast or slow machines that > could otherwise perfectly handle the load and needlessly burning CPU > cycles on fast ones. > > If your machine is fast enough, go ahead, add vo=x11 to your > configuration file. But using this as a package default is going to do > a lot of damage for almost everybody else. Not to mention that the -zoom > option is necessary to get scaling at all then. Why a lot of damage? How many machines are too slow for software scaling? Also, why is burning CPU cycles a big issue? The typical desktop user won't be doing anything else when displaying a video, specialy when scaling takes place and the video runs in full screen. OTOH, the power user who is compiling things and running boinc will have an idea how to tune up her mplayer. Also, we could take as a compromise solution to rise the template severity and make it clearer to the user what advantages and disadvantages do software and hardware scaling have. > > Sorry, I didn't explain well. I _can_ take screenshots, it's just that > > the video is displayed blue. This is not a Beryl bug, it'll happen to > > everything that captures the X display. > > > > See attached screenshots. In one of them, video appears to be completely > > blue, but in the real screen I see the video in 2D. I.e. as if after > > rotating the display the video was inserted only in the blue part (without > > rotation). > > I perfectly understood what you were referring to. I'm well familiar > with this effect. This is because X does not handle the overlay video > memory directly. Now why don't you try the screenshot filter as I > suggested? That's a workaround. For plain screenshots it'd be enough to enable this workaround by default. For Beryl, we would need another workaround, and presumably a more complicated one. We shouldn't assume that is even possible to do that sanely. Later, other programs might have similar problems, etc. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
