On Thu, Oct 21, 2004 at 03:35:21PM -0700, Ian Romanick wrote: > Dieter Nützel wrote: > >Am Freitag, 15. Oktober 2004 22:51 schrieb Nicolai Haehnle: > > > >>There is disagreement about the meaning of the CLIPSPAN _n parameter in > >>CVS. > >> > >>The drivers I have looked at and drivers/dri/common/spantmp.h treat _n as > >>the number of pixels in the span after clipping. > >>depthtmp.h and stenciltmp.h treat _n as the end+1 x coordinate of the > >>span. > >> > >>This inconsistency leads to artifacts when software fallbacks are hit > >>while > >>clipping is used, especially with partially obscured clients. The attached > >>patch should fix these artifacts by changing depthtmp.h and stenciltmp.h > >>appropriately. > > > >What about this? > > > >Needed? > > I could have sworn this patch already got committed. In any case, it > looks good to me. I didn't realize the the templates in depthtmp.h > treated the _n parameter differently than the ones in spantmp.h. The > fix, as in this patch, of making depthtmp.h work like spantmp.h seem to > be the right one. The other option would be to fix each driver that > uses depthtmp.h.
I think this fix is better. _n is the original number of pixels and _n1 is the clipped number of pixels. It feels like the least confusing way to me. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
