Re: [Xpert]Using MMX assembly (for video card drivers)
> I've also been playing with some mmx-ification of the XVideo routines, > for example I also did an SSE-4:2:0-to-4:2:2 function. I just did this too, MMX only though. How many cycles/pixel did you end up with? What percentage of pairing did you achieve? > There was some discussion on #xfree86 about efforts to have a nice > runtime detection mechanism somewhere. Has anyone got any code for this > already done? If not I might also have a go at it. there are plenty of samples of this on Intel's site. --greg ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]X11 clipbox
Daniel Secrieru wrote: [snip] > I had a lot of problems with incompatibilities between the two and this > clipbox stuff is the latest. In Win32 there is a function called GetClipBox, > that does the following (quote from MSDN): > > 'The GetClipBox function retrieves the dimensions of the tightest > bounding rectangle that can be drawn around the current visible area on the > device. The visible area is defined by the current clipping region or clip > path, as well as any overlapping windows.' > Doesn't this just sound like the same thing as taking all your expose events, unioning all the rects together and takeing the extents of the resulting region? --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
"Sottek, Matthew J" wrote: > > XV_FRAME_TYPE = XV_HOLD > XvShmPutImage() > ... > XvShmPutImage() > ... > XvShmPutImage() > XV_FRAME_TYPE = XV_FRAME > > The target of the XvShmPutImage will only change when XV_HOLD is > set. (Or if XvShmPutImage is called without XV_HOLD) So however > many XvShmPutImage()'s get called while in XV_HOLD get put in the > same place overwriting each other. Once I get an implementation done > I'll write up some clear documentation. > > -Matt You and Mark were right, I was still thinking they were bit fields. But, I still have a question on the above example. In a follow up post Mark points out that the XV_FRAME_TYPE (or whatever it ends up being called) is a write only atom that takes effect on the next put. Is that the case? If so, The above won't work right? Just setting XV_FRAME_TYPE to XV_FRAME will not display the last held frame, instead, it won't do anything until the next put which will have new data. or am I confused again? --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
"Sottek, Matthew J" wrote: > > >"Sottek, Matthew J" wrote: > >> > >> Here is the proposal again, if there are on complaints I'll > >> implement it this way. > >> > >> #define XV_HOLD 0x0 > >> #define XV_TOP_FIELD0x1 > >> #define XV_BOTTOM_FIELD 0x2 > >> #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) > > > >Just to clarify, the default atom value will be XV_FRAME right? > > Yes, existing Xv clients do not need to change anything. It will > works just like it always has. Clients can query for the > XV_FRAME_TYPE atom to see if the driver supports this new > functionality. I plan on resetting it whenever the Overlay is > turned off. Another question real fast. If I blt a frame with the XV_FRAME_TYPE atom set to XV_FRAME|XV_HOLD, and then, sometime later, I set the atom to XV_FRAME, what kind of latency would I be looking at before that held buffer would show up? Is setting atoms a synchronous call? Would I be certain the frame is on the screen when it returns? I don't really care which way as long as Can it be required that all XV_HOLD --> !XV_HOLD transitions happen in the vblank somewhere? That way I can just worry about setting the atom as close to frame display time as I can and not worry about the tearing. I guess I am just looking for another way to work around not getting vsyncs at my level. Now that I think about it, what effect, if any, will this have on drivers that implement their own multi-buffering? Another clarification question, what happens in this case: XV_FRAME_TYPE = *|XV_HOLD XvShmPutImage() ... XvShmPutImage() ... XvShmPutImage() XV_FRAME_TYPE = *&!XV_HOLD I take it that only the last frame put will show up? --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert] Xv hit list
"Sottek, Matthew J" wrote: > > Here is the proposal again, if there are on complaints I'll > implement it this way. > > #define XV_HOLD 0x0 > #define XV_TOP_FIELD0x1 > #define XV_BOTTOM_FIELD 0x2 > #define XV_FRAME(XV_TOP_FIELD | XV_BOTTOM_FIELD) Just to clarify, the default atom value will be XV_FRAME right? --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]very strange XVideo behaviour (i810)
Mark Vojkovich wrote: > > On Fri, 19 Oct 2001, Pranay Kumar wrote: > > > > It would indeed help if Xv could be used to hardware scale RGB surfaces. > > > >One thing I've never been clear on is what the FourCC codes > for RGB surfaces are supposed to be. I'm not sure where to > find standards on that. Try here, it is a pretty good list to start with: http://www.webartz.com/fourcc/ --greg. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
