Re: [xine-devel] video width and height

[Christer P. <pa...@no...>]

Miguel Freitas wrote:

>>Yeah, it would probably look quite bad - at least for up-scaling, but it 
>>would be "best effort" I suppose.
>>
> 
> Feel free to implement. Guenter likes the scaling idea too, so i would
> have nothing against commiting it.
>  


Yeah, I will have a look at it as soon as I get some spare time (which 
may not happen in the nearest future, so if there are any other 
takers... :-) )

> 
> Another function please... I don't like the idea of inserting lots of
> flags into osd, you'll only make the initialization full of parameters.
> 
> osd->show(...)
> osd->show_scaled(...)
> 
> It's shows very clearly what they are supposed to do, imho.
> 


OK, I'll keep that in mind.

> 
> Humm...no. If the osd client is drawing over a 1024x768 area expecting
> to blend it after scaling that poor 160x120 video fullscreen, and the
> driver can't do that, the user will see no osd.
> 


Why would it expect that??
It will of course have to 1) ask OSD about the blending resolution and 
create properly sized overlays accordingly, or 2) ask OSD to do scaling.

I don't see how this could be any worse than the current situation?

> If the osd client knows that it can only be blended at 160x120 he can
> use smaller fonts or tell the osd to rescale it. That's a big
> difference.


Exactly! That's why the osd->get_blending_resolution() whatever function 
has to return the actual blending resolution. 160x120 if the current 
output driver can only blend at video resolution, 1024x768 if it can 
blend at output resolution. XXXxYYY if the driver can do some other magic.

> 
> Adding new functions after the existing ones will not break
> compatibility. Not even at binary level.
> 


I wasn't primarily thinking about binary compatibility this time. IMHO 
it's better to do something flexible up-front instead of adding new 
stuff on top to fix things that wasn't thought of the first time around. 
But let's leave that for another thread...


> 
> Have you realized that osd renderer doesn't actually knows the blending
> resolution?
> 


Yes, I know. This really has to come from the output driver, but 
API-wise it should be in the OSD API.

> It doesn't mean it should stay that way, but i'd like to explore a
> little better the already existing FRAME_CHANGE event before including
> osd callbacks.
> 


As I wrote in response to Christian, I think it's very important to keep 
the concept of overlays separate from video concepts. In the future, 
overlays and video may not have the same resolution, they may not change 
size at the same time, and *drumroll* we may even have overlays without 
video (yes, OSD is useful in audio playback situations, too!).


-- 
Christer Palm