Re: [xine-devel] xine plugin

[Zubin D. <zu...@ji...>]

Yes, I see.  You can certainly pass around pointers to data in the same
address space.  However, that means you need to have the whole address
space replicated.  That was my first point, that fork() will replicate
the whole address space.  Granted, the pages are not going to get
physically copied because of COW, but nonetheless, this seems to be an
unnecessarily hefty operation given the number of PTEs used by a program
like a browser. Isn't it?  I'm thinking that each time you make a call
to the other process (with the pointer), there will be a context switch
and the TLB will get flushed.  Thus, xine's PTEs will have to keep
getting reloaded into the TLB each time there is a context-switch, and
this is likely to cause a performance hit.

I still believe it is better for performance reasons to let the
application handle its own streaming.  There are bound to be unnecessary
additional copies if it goes through the browser.  And given we can't do
any other kind of streaming than http streaming by going through the
browser, it seems of limited use to me to use the browser's HTTP engine
given xine already has its own.

Regards,
-Zubin


On Thu, 2001-12-27 at 07:39, Hallvar Helleseth wrote:
> The way you think the context switching occurs is wrong. I've never
> looked at the code your referancing to but anyways...
> The idea of context switching in this form is just passing the _address_
> to the area in memory where that structure (or Object as in java if you will) resides. this way both the calling function and the function called can operate on the SAME structure (not on two duplicates). The same applies for Java when using Objects. You should read some C tuturials on pointers :)
> 
> Anyways hope this clears out what you were thinking of :)
> 
> Regards
> Hallvar Helleseth
> 
> * Zubin Dittia (zu...@ji...) wrote:
> > I checked out the xine-plugin source and have been taking a closer look
> > at it.  I'm pretty new to xine and to GUI progreamming in general, so
> > don't hesitate to tell me I'm full of it... but I think I see a problem
> > with the current way in which things are being done -- it seems to me
> > that a new process will get forked for xine, but that process will have
> > the entire context of its parent, which is the browser itself.  Given
> > how much memory browsers use these days, this seems awfully wasteful.
> > 
> > A second problem is that all data will have to pass between the browser
> > process and the xine process, which will mean lots of copies and
> > constant context switching, which may lead to poor performance.
> > 
> > Am I correct in the above observations?  If so, I see two ways around
> > these problems:
> > 1. Run xine in the same process as the browser.  Since xine is
> >    multi-threaded, I'm not sure if this is even possible (or if it is,
> >    how it will interact with browser threads).  (I've never done
> >    any multi-threaded programming (except in java), so pardon my
> >    ignorance).
> > 2. Run xine in a separate process which is vfork'd, and which execs a
> >    xine_plugin executable.  The browser plugin would communicate with
> >    the xine_plugin process using RPC calls.  In order to limit this
> >    communication to control information only (e.g., window changes),
> >    the xine_plugin process would have to do its own data streaming.
> >    This is desirable for two reasons: (a) http streaming support is
> >    already part of xine (although it doesn't seem to be fully
> >    functional yet -- it crashed when I tried to use it), and (b) in the
> >    future, we might want to do streaming other that http streaming,
> >    for example we might want to implement MMS streaming.
> > 
> > I am leaning towards the second option.  In fact, I believe it may be
> > advantageous to create a browser plugin which is more general and
> > applies not just to xine, but to all kinds of applications (along the
> > lines of plugger.so).  The main difference from plugger is that it would
> > have interactions with the application process even after it has been
> > launched, and it wouldn't deal with any browser-based streaming, or rely
> > on data being stored in a local file, instead assuming that the
> > application will deal with its own streaming.  It might perhaps even be
> > possible to extend plugger to achieve this.
> > 
> > I am envisioning that the plugin application to be launched will be
> > determined by lookup in a mailcap file, and that application (e.g.,
> > xine_plugin) will be launched in a separate process, with all the
> > arguments to NPP_New() passed in as parameters (e.g., the SRC, Width,
> > Height, etc. obtained from the EMBED tag on the web page).  In this
> > case, the plugin application will treat the value of the SRC tag as the
> > URL it should stream from, and open a direct connection to the
> > corresponding host.
> > 
> > We also define an RPC API to inform the plugin application process
> > whenever the window within the browser changes (the plugin's
> > NPP_SetWindow() function gets called when this happens), or when the
> > browser calls NPP_Destroy().  What kind of RPC API would make sense
> > here?  CORBA?
> > 
> > I'd be willing to define the API and write such a generic netscape
> > plugin if folks feel this is the right approach.
> > 
> > regards,
> > -Zubin
> > 
> > 
> > _______________________________________________
> > xine-devel mailing list
> > xin...@li...
> > https://lists.sourceforge.net/lists/listinfo/xine-devel
> >