[MPlayer-dev-eng] [PATCH] bugfix for black bar besides gaussed vobsubs

[D Richard Felker III]

On Sat, Jan 08, 2005 at 06:24:20PM +0100, Reimar Döffinger wrote:
> Hi,
> On Sat, Jan 08, 2005 at 12:08:37PM -0500, D Richard Felker III wrote:
> > On Sat, Jan 08, 2005 at 03:33:37PM +0100, Reimar Döffinger wrote:
> > > On Sat, Jan 08, 2005 at 02:52:05PM +0100, Csillag Kristof wrote:
> > > > 2005-01-08, szo keltezéssel 11.35-kor Reimar Döffinger ezt írta:
> > > > > How about memset(d2, 255, ds*dh); before scaling? Probably not much
> > > > > slower (well, when I look at that code I think speed wasn't really much
> > > > > considered anyway) and easier to understand.
> > > > > Think that should work, too...
> > > > Now that you mention it, the following solution is faster and alsa more
> > > > simple (both to do, and to understand). (See attached patch!)
> > > > 
> > > > Here is how it works now:
> > > > 
> > > > 1. It gets the alpha values straight:
> > > > 	- 0 means totally transparent
> > > > 	- 1 means almost totally transparent
> > > > 	- 255 means not transparent at all
> > > > 	(Until so far, we set the values to the
> > > > 	_opposite_ values before scaling.)
> > > > 
> > > > 2. Scales up the stuff.
> > > > 	(The padded parts are 0 - that's totally transparent,
> > > > 				 no more problem)
> > > > 
> > > > 3. Reverts the alpha values to the "normal" way:
> > > > 	- 0 still means totally transparent
> > > > 	- 1 is not transparent at all
> > > > 	- 255 is almost totally transparent
> > > > 
> > > > 	(May I ask, why do we use this interpretation? It's a pain...)
> > > 
> > > Agree, I dislike it and it should be changed. I think it's because it
> > > was like that in the first OSD implementation (and is used when you
> > > define FAST_OSD). Not 100% sure though.
> > 
> > Definitely should not be changed. It's written this way for a reason,
> > to optimize the alpha blender, which is called on every frame. OSD is
> > already slow enough..
> 
> I think it is only used for a comparison... If a comparison against 255
> is so much slower than against 0... But I don't know the details..

It's larger. And this can mean slower if cache is an issue.

> > > Wouldn't 256 - s2[i] (which is by the way equivalent -s2[i]) make more
> > > sense than (s2[i] - 1) ^ 255 ??
> > 
> > I dunno, if you have a way that works it's ok, but my code is correct
> > and not slow anyway.
> 
> Huh? And what about that black stripe then? That's intended??? Or what
> do you mean?

I just mean the (s2[i] - 1) ^ 255 thing. Obviously the black stripe is
wrong and needs to be fixed.

Rich