#12206 NORM 13.1.0: XO-1.75 rotation rendering error

Zarro Boogs per Child bugtracker at laptop.org
Thu Dec 20 11:37:05 EST 2012

#12206: XO-1.75 rotation rendering error
           Reporter:  greenfeld        |       Owner:  jnettlet                         
               Type:  defect           |      Status:  new                              
           Priority:  normal           |   Milestone:  13.1.0                           
          Component:  x window system  |     Version:  Development build as of this date
         Resolution:                   |    Keywords:                                   
        Next_action:  review           |    Verified:  0                                
Deployment_affected:                   |   Blockedby:                                   
           Blocking:                   |  
Changes (by dsd):

 * cc: dsd (added)
  * next_action:  diagnose => review


 There are 2 bugs here.

 Firstly, rotation of "nearest" interpolation images produces bad results,
 as can be seen on the first and third rows of the output. (the bilinear
 interpolation used on the second and fourth rows is rejected by the EXA
 path in the driver, so it is rendered in software).

 This rotation causes a composite operation with an appropriate
 transformation matrix applied. However, the dove driver only handles the
 transformation matrix in a simple way that will only work for scaling. So
 we should refuse to accelerate other types of matrix, such as rotation.
 Fixed in only-scale-transforms.patch


 The second bug can be seen in the third image on the first row. This is
 the scale operation where the original image is enlarged. If you look
 carefully you can see some yellow and grey pixels on the very left side
 near the bottom, and also the whole image is shifted right a bit by that
 (it is missing the final vertical row of pixels - you can see the image is
 not quite symmetrical). The same applies on the other plane; the image has
 a spurious row of white pixels at the top, and is missing the final row of
 pixels at the bottom.

 The scale operation again hits a composite path with a transformation
 matrix, and in this case the matrix is a scaling matrix which we can deal
 with. However, the translation of coordinates after applying the matrix is
 not totally accurate, resulting in an off-by-one error and causing this
 bad rendering (we start the composite op from one pixel before where the
 source drawable starts, in both dimensions). Fixed in transformation-

Ticket URL: <http://dev.laptop.org/ticket/12206#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system

More information about the Bugs mailing list