Re: [xine-devel] Increasing CPU-load with sample from website

[Carsten H. (T. R. <ra...@ra...>]

On Sun, 11 Sep 2005 19:56:56 -0300 Miguel Freitas <mfr...@gm...> babbled:

> On 8/10/05, Jason Tackaberry <ta...@sa...> wrote:
> > You can use XPending/XNextEvent in lieu of XCheckEvent.  Something like
> > this:
> > 
> >         XLockDisplay(display);
> >         if (XPending(display)) {
> >            got_event = 1;
> >            XNextEvent(display, &ev);
> >         }
> >         XUnlockDisplay(display);
> 
> oh boy. that problem with picking x events again... i have changed
> this code so many times already and every time i believe it is the
> ultimate solution ;-)
> 
> a bit of history: xine uses shared memory for sending frames to X11
> server and then it must wait for "completion events" before drawing a
> new frame. originally xine-ui received all events and forwarded the
> completion events to xine-lib so xv/xshm drivers would be happy. then
> i noticed somewhere else (mplayer? i don't remember) that XSync could
> be used inside of xine-lib to avoid having to explicitely parse
> completion events.
> 
> i guess Daniel came with the XCheckMaskEvent solution to avoid
> receiving completion events and let them be processed by xine-lib. but
> now that i think about this, the important thing is making sure the
> drawing request is processed by X server and completion event is
> received (this is what XSync does, right?) but whether the event
> itself is processed by the application is irrelevant. in fact, XSync
> will not process the event!

XSync(display, False); is the way to go - put that right after XShmPutImage();
basically XSync sends a harmless request to x and waits for the reply TO THAT
REQUEST ONLY. being x - it guarantees order of operation. that means do request
A then request B, x guarantees it will have done request A before request B,
thus doing a XSync - by the time it returns, you are guaranteed to have done
the put image. this does mean XSync() will block waiting for x to copy the shm
segment contents out to the gfx device, but generally this is a short period of
time. the only time you really want to be using completion events if you want
to do more async decoding - which you are doing in other threads anyway. (ie
start decoding a new frame while you want for x to copy the only one up). this
would only be of uses if you were deocindg/generating frame pixels in the same
thread as the XShmPutImage(). Another trick you can pull is to actually only
call an XFlush() after XShmPutImage, keep the image struct and segment around
until the NEXT time you need to draw the NEXT frame, THEN call XSync() just
BEFORE you fill in the image pixels. This means the XSync will do a quick round
trip - IF x was so slow it hadn't copied the frame out yet, well you will block
and wait for it to be done before refilling the shm image pixels, but the
chances are farily low so you have allowed x to async copy the pixels out WHILE
you are preparing the next frame. you will ONLY block IF x cannot copy frames
up as fast as you can generate them - this will eventually spill back into
dropping frames anyway so it's no big deal :)

i definitely suggest XSync as being your much cimpler solution. :)

> > Having done this myself, it seems that there are regular events of type
> > 95.  Looking through X.h, I have no idea what event this is.  Maybe
> > someone who understands X11 could explain?
> 
> could it be (XShmGetEventBase(gXitk->display) + ShmCompletion) ?
> 
> your solution looks good to me. do you think it is safe to update all
> docs+xine-ui to use this approach instead?
> 
> Miguel
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> xine-devel mailing list
> xin...@li...
> https://lists.sourceforge.net/lists/listinfo/xine-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...
裸好多                              ra...@de...
Tokyo, Japan (東京 日本)