On Thu, Aug 15, 2002 at 02:53:07AM +0200, Sven Neumann wrote: > hmmm, now that you mention this ... how well does the current patch > deal with an odd number of rows in FillRectangle?
Since the chroma coordinates and size are divided by two things will be somewhat wrong on the edges. So any odd coordinates are a problem. There is also a problem with packed YUV formats. The patch uses 32bit macropixels but bpp for these surfaces is 16. Now imagine what will happen if the x coordinate isn't an even number: chroma samples will swap places. Blitting is done with 16 bit pixels so it doesn't have this problem. But blitting does have the problem that chroma values on the edges can be somewhat wrong when one comes from the destination and the other from the source surface. I think a correct fix would be to recalculate the chroma samples for the edges. But that will need code to handle the edges as special cases. A simpler fix would be to restrict all coordinates to even values. But this will not help FillTriangle with planar formats. Chrominance subsampling is quite an annoyance :( > > AFAICS your patch doesn't check what drawing operation is requested. So > > anything using gDrawLine() will succeed but the results will not be > > correct. > > I removed it since your patch duplicated the code that checks the > drawing operation quite often. We should perhaps try to find a better > place for the check. Yep. I didn't like the duplicated code either. Doing the checks in one place will most likely require another switch (or if) statement. > Before YUV surfaces have been introduced the software driver used to > provide fallbacks for all operations. Since then we broke this rule > since implementing all operations for all pixel formats would be a > major effort and would add a good amount of code that would rarely be > used (if ever). Well my original intention was to get Clear working. Anything beyond that is a bonus. Most likely Clear with black color is the only thing really used. StrethBlit might be used too. Just had an idea... Wouldn't StretchBlit for planar formats be as simple as using Bop_PFI_Sto_Aop_8()? Just convert gStretchBlit() to handle the planes like gBlit(). I don't have time to test right now... > On the other hand it would be nice to support all kinds of drawing > operations for YUV surfaces. I think they could be implemented by > adding a few more steps to the rendering pipeline instead of adding > extra code to all drawing functions. I'll see if I can spend some > time on this next week... If you get something done I'll be here to test and comment. -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
