#12206 NORM 13.1.0: XO-1.75 rotation rendering error

[Zarro Boogs per Child]

#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


Comment:

 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-
 rounding.patch

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