[MPlayer-dev-eng] [**13 ESSENTIAL PATCHES**] Libass enhancements that need to coincide with the new EOSD patches

[Grigori G]

On Mon, 23 Feb 2009 19:16:44 +0100, Reimar Döffinger
<Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
> Uh, the matrix used in the code is
> [[1,2,1], [2,4,2], [1,2,1]]
>

Yes, typo in the comment(s). It's supposed to be [[1,2,1], [2,4,2],
[1,2,1]].

> 
> Is that return value ever used? Otherwise you could just use one
> function.
>

Yes, in parse_tag at least (ass_render.c).

> 
> Is it _exactly_ the same code as vsfilter? Because that code does not
> blur the borders at all.
>

I don't know whether it's *exactly* the same in this regard (border
handling), but the bitmap is enlarged a bit before blurring, so that
skipping the border pixels isn't visible.

>> +	for (y=0; y<h; y++)
>> +		for (x=1; x<w-1; x++) {
>> +			p = buf[y*w+x-1];
>> +			p += 2 * buf[y*w+x];
>> +			p += buf[y*w+x+1];
>> +			p = p >> 2;
>> +			tmp_buf[y*w+x] = p;
> 
> This can be done with less calculation:
> for (y=0; y<h; y++)
>     old_sum = 2 * buf[0];
>     for (x=0; x<w-1; x++) {
>         new_sum = buf[y*w+x] + buf[y*w+x+1];
>         buf[y*w+x] = (old_sum + new_sum) >> 2;
>         old_sum = new_sum;
>     }
> which is also in-place, thus halving the memory bandwidth requirements
> and blurs the left border. Right border is still not handled though.
>

I'm sure the current code isn't optimal...
I first wanted to do it in place, too, but had some very odd issues with
it. I'll look into that again.

> The same principle could be applied here, though traversing the image
> column-wise is putting a very high strain on the cache (though that is
> the same as the current code), usually you would process at least one
> cache-line of data horizontally at once, though performance may not
> matter enough to justify the complexity here.
>

It sure doesn't... also, \be is usually applied to small bitmaps and thus
the cache strain probably doesn't matter much.

Grigori