Bug 5796 - fbComposite copy function selection is broken
Summary: fbComposite copy function selection is broken
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Xorg Project Team
QA Contact:
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2006-02-03 05:05 UTC by Matthias Hopf
Modified: 2006-06-21 08:17 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Attachments

Description Matthias Hopf 2006-02-03 05:05:29 UTC 
During investigation of bug #4320 I found several bugs in fbComposite, which
*accidentially* actually accelerated the copy process. In these corner cases no
harm was done, but it could be possible.

This bug is here for tracking and for discussion whether I'm right here.

1st) fbpict.c:845
     Bool srcRepeat = pSrc->pDrawable && pSrc->repeat == RepeatNormal;
  should IMHO read (RepeatPad & RepeatReflect weren't honored)
     Bool srcRepeat = pSrc->pDrawable && pSrc->repeat;

2nd) fbpict.c:893 & 1068
   The else part of
      if (srcRepeat &&
          pSrc->pDrawable->width == 1 &&
          pSrc->pDrawable->height == 1)
   labels /* has mask and non-repeating source */
   but is also hit if width or height are != 1. In these cases AFACS
   the slow path should be taken.
   Perhaps the same methology as in bug #4320 could be used for
   improving the number of fast path cases.

Any thoughts?
Comment 1 Matthias Hopf 2006-05-11 21:23:56 UTC 
No answer for a long time
-> commited to HEAD.

Ajax, something for RC3? (If it's not too late)
Comment 2 Matthias Hopf 2006-06-21 08:17:11 UTC 
Fixed in git long ago.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.