From: James Courtier-D. <Ja...@su...> - 2002-01-17 15:12:04
|
> -----Original Message----- > From: Miguel Freitas [mailto:mi...@ce...] > Sent: 17 January 2002 13:50 > To: Ja...@su... > Subject: xine overlays > > > Hi James, > > Again, great work on dvdnav! All my dvds are working now except Lethal > Weapon 4 where i don't see highlights at all (that's another story since > it never worked). There is not much I can do about this without having the DVD itself. > > I just found a minor problem, one dvd that work perfect with old > clipping scheme (using xshm) now renders overlays incorrectly. Basically > the highlight color is bleeding left to outside of the image but inside > the clipping area. (ie. the area supposed to be transparent inside the > clipping box gets a wrong color) I guess it might be a bug in > blend routine. Can you describe this a bit more so that it is not ambiguous to me what you are actually meaning. E.g. ************************************** * * * ************** * * * * * * <<<* * * * * * * * * * * * ************** * * * * * ************************************** Where <<< is where the bleeding happens, taking colour from the Highlight area in the middle and applying it to the outside bit of the overlay. > > This leave to think about changing the xine overlay format. What do you > think of moving it again to a bitmap format instead of rle encoded? xine originally had a bitmap format. Which was the format I started with. I can tell you now, bitmap format is very very slow compared to rle format. So I really don't want to go back to bitmap format unless you can prove it will be quicker. Also, the mem_blend8 method is currently wrong for the Y'CrCb format (which is what we are using, we are not using yuv.), so don't bother with an MMX version yet. (see my comment in the code) > > I have doubts if the performance advantages of using rle bitmaps (like > ability to do memset's) are still valid with all the special clipping > cases we must treat now. Also OSD overlays are less likely to gain from > rle encoding than spu ovelays. Please consider that DVD menus use an overlay which covers the entire display area. Bitmaps for an entire display area would significantly slow things down I think. > > Using overlay bitmaps may have some benefits: > > - simpler code in alphablend (no need to take care of that clipping cases) We will still have to take care of clipping cases, because the colours of the menu buttons change. > > - no need to compress bitmaps on every OSD show. Not very difficult, as we already do it, and it only gets done once per show, and not once per frame. > > - possibily better performance I highly doubt it, but will change that view if proved otherwise. > > - less error prone Once we get it right, we can forget about it. We obviously just have a small bug. I expect it is due to the > or >= comparisons in the clipping code. > > - easier to make future optimizations like using MMX (the MMX > instructions aren't suited for codes with several branchs and loops like > the current one) We only need to optimise the mem_blend functions, not the entire overlay_blend routine. if statements take no time at all, memcopy and mem_blend operations do. > > > Comments? Should we bring that discussion to xine-devel? Yes, I have done with this email. > > regards, > > Miguel > |