[vlc-devel] Re: Python+wxPython bindings on Mac (patch)

[Jan David Mol]

Damien,

Sorry I did not reply earlier, I missed this in the list of VLC  
emails :(

On 25-mei-2007, at 11:39, Damien Fouilleul wrote:

> i was actually thinking of adding an extra API, such as,  
> libvlc_video_set_drawable_type() to allow passing different type of  
> drawable to the vout handler, not necessarily limited to MacOS X  
> drawable types, this has the nice advantage to be backward  
> compatible with existing api.
> You would still use libvlc_video_set_drawable() to pass a reference  
> to the drawable.
>
That would indeed be a better solution, as similar problems could  
occur on different platforms with different APIs or even different  
versions of the same API. I cannot test non-Mac changes though, so I  
kept myself to Mac-specific stuff.

> I was reading your previous emails, and I don't understand why you  
> need the vout to call InvalidateRect() after an aglSwap(), since  
> the latter would repaint the video.

Indeed, that's what I thought as well. However, unpatched, aglSwap  
will repaint the video, but the window will not be repainted. A  
redraw will then only happen if forced by the OS (obscure+unobscure  
the window, etc). I do not know why the unpatched code does work in  
VLC.app and presumably the mozilla bindings, but adding an  
InvalidRect call was sufficient for actual repainting in case of  
wxPython integration, which was my aim.

> regarding resize, you should call libvlc_video_set_viewport()

When I tried that several weeks ago, set_viewport crashed in (for me)  
a quite obscure way. Aparently that was a glitch as it seems to work  
now. Weird, but I'm not complaining :)

I looked at similar situations in VLC and found the following:
* wxPython integration under Windows and Linux do not need a  
set_viewport/set_size call.
* DirectX does its own checking and adjusting (modules/video_output/ 
msw/directx.c:562)
* the Mac QT port requires one to set the "drawableredraw" variable  
to 1 (modules/gui/macosx/voutqt.m:504)
* ports like SDL and X11 detect their own resizing and handle it  
accordingly (modules/video_output/sdl.c:559 and modules/video_output/ 
x11/xcommon.c:1468).
These all decide upon the window size themselves, so at most a signal  
is given.

Personally, I like letting wxPython informing VLC about size changes,  
but to stay consistent with the situations above, I chose for auto- 
detecting the size changes in aglManage. The VLC code detects the  
window and windowborder size, so why not the control (viewport) size  
as well.

It's easily modified to require a set_viewport call or even a  
'drawableredraw' instead, if the VLC devs prefer it in this case.  
I'll resubmit the adjusted patch if desired.

Jan David

>
> Damien
>
> Jan David Mol wrote:
>> Hi,
>>
>> Thanks for your input. I'm processing this, and will post a patch  
>> again when done. I am also looking at having wxPython call some  
>> onresize function in vlc instead of having vlc check every frame  
>> whether the window size changed (which is my code now, and is  
>> rather ugly).
>>
>> Jan David
>>
>> On 19-mei-2007, at 17:15, Pierre d'Herbemont wrote:
>>
>>> Hello Jan,
>>>
>>> On 19 mai 07, at 12:19, Jan David Mol wrote:
>>>
>>>> I just finished obtaining VLC playback under wxPython on Mac.
>>>
>>> Nice!
>>>
>>>> My modifications may break other stuff and require some ugly  
>>>> hacks (imho), but do get the job done. I like any advice on how  
>>>> to proceed or fix these issues.
>>>
>>>
>>> You could simply expand the drawable to a pointer to a structure  
>>> like this:
>>>
>>> enum macosx_drawable_type_t
>>> {
>>>     VLCDrawableControlRefType,
>>>     VLCDrawableAGLDrawableType,
>>>     VLCDrawableNSViewType
>>> }
>>>
>>> struct {
>>>     enum macosx_drawable_type_t type;
>>>     union value
>>>      {
>>>         ControlRef control;
>>>         AGLDrawable agl;
>>>         NSView * view;
>>>     }
>>> }
>>>
>>> Then your code could be isolated well from the existing code  
>>> which is used by the mozilla plugin.
>>>
>>> Pierre.
>>>
>>> -- 
>>> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
>>> To unsubscribe, please read http://developers.videolan.org/ 
>>> lists.html
>>>
>>
>
> -- 
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
>

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html