[MPlayer-dev-eng] [PATCH] Dynamic list of EOSD sources
Nicolas George
nicolas.george at normalesup.org
Wed Sep 15 14:44:29 CEST 2010
L'octidi 28 fructidor, an CCXVIII, Reimar Döffinger a écrit :
> This loop and the one in eosd_image_first do the same thing
> and so should use the same code.
I think I managed to factor it satisfactorily.
> I'd also suggest writing eosd_image_first as
> images->source = images->first_source;
> images->image = images->source->images;
Does not work if images->first_source is NULL. But this part is gone anyway.
> Looking at the code without inlining doesn't give you any useful information
> at all.
I was not clear: I disabled the inlining of my_draw_bitmap to see if the
cause of the performance loss was a change in the code. I found that:
- master/my_draw_bitmap-inlined and master/my_draw_bitmap-not_inlined
have no visible difference of performance;
- dynamic/my_draw_bitmap-inlined and dynamic/my_draw_bitmap-not_inlined
have no visible difference of performance;
- dynamic/my_draw_bitmap-* is significantly slower than
master/my_draw_bitmap-*;
- dynamic/my_draw_bitmap-not_inlined and master/my_draw_bitmap-not_inlined
have exactly the same assembly code.
> Turion is the cheap model, I can't imagine it has more cache.
It probably has less. It may exhibit the "bad" performances on both cases.
> I'd also suggest to try marking the while loop that looks for the next source
> as unlikely (using __builtin_expect).
For my tests, I went further: I replaced eosd_image_next by image->next,
since there was only the ASS source. It did not change anything at all. If I
remember correctly, eosd_image_next amounted to less than 1/100 of the total
time.
> But I think the performance degradation is acceptable if necessary, it
> should be easy enough to optimize this if necessary/wanted.
I believe so too. Furthermore, I think that vf_ass was not especially
optimized: I quickly tried two small ideas (separating the loops for Y, U
and V, and removing a division using some arithmetic) and the speed gain was
greater than the performance loss we are discussing. This belongs in a
separate patch, though.
Attached: updated version:
- Added a eosd_image_remove function, useful for the next patch and probably
other future sources.
- Code factored between eosd_image_first and eosd_image_next.
- Some more = aligned.
- Bugfix: images->changed was not set.
- VDPAU STILL UNTESTED.
Plus, the slave command overlay_add:
- Updated to the new API. Much simpler than the previous version.
- Added the documentation.
Regards,
--
Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-eosd-01-dynamic-20100915-1438.diff
Type: text/x-diff
Size: 23095 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100915/344c98ee/attachment-0002.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-eosd-02-command-20100915-1438.diff
Type: text/x-diff
Size: 4882 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100915/344c98ee/attachment-0003.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100915/344c98ee/attachment-0001.pgp>
More information about the MPlayer-dev-eng
mailing list