[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xine-devel
Subject:    [xine-devel] alphablend in libxine.so [was: overlay blending with VO cropping on drivers without VO_
From:       Miguel Freitas <mfreitas () gmail ! com>
Date:       2005-09-25 0:03:53
Message-ID: f9eabcda05092417031d6e4bc1 () mail ! gmail ! com
[Download RAW message or body]

Hi Jason,

On 9/24/05, Jason Tackaberry <tack@sault.org> wrote:
> Might I suggest including the alphablend code in the external API so
> that those front-ends that develop their own vo drivers can take
> advantage of this code?

i have considered this before and i never really managed to make the
switch mostly because of lazyness.  i thought current scheme would win
for reduced memory footprint because vo plugins would not include
functions they don't use (eg. xshm and yuv blend) but it is wrong: all
vo plugins are linked to alphablend.o therefore they get all blend
functions. it would only be different if alphablend were a static
lib...

so unless anybody objects, i will move it to libxine.so. nothing
should change in terms of memory usage (provided that xine loads at
least one vo plugin), but vo plugins will use less space on disk.

please note that following xine's convention, functions will not be
"public xine api" (the ones xine_) but rather "internal" functions
(_x_). the main diffence is that public api is what is used by
frontends and is guaranted to be stable in 1.x series.

Miguel


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
xine-devel mailing list
xine-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xine-devel

[prev in list] [next in list] [prev in thread] [next in thread]