#12675 BLOC 13.2.0: Zooming in Browse decreases perfomance

[Zarro Boogs per Child]

#12675: Zooming in Browse decreases perfomance
------------------------------------+---------------------------------------
           Reporter:  reuben        |       Owner:  dsd          
               Type:  defect        |      Status:  new          
           Priority:  blocker       |   Milestone:  13.2.0       
          Component:  not assigned  |     Version:  not specified
         Resolution:                |    Keywords:               
        Next_action:  never set     |    Verified:  0            
Deployment_affected:                |   Blockedby:               
           Blocking:                |  
------------------------------------+---------------------------------------

Comment(by dsd):

 Yes, upon zooming into this page, the stream of requests that reaches the
 driver changes drastically. Notably, there are a lot of bilinear scaling
 operations requested when zoomed in, which seems logical. And
 CheckComposite in xf86video-dove is rejecting these operations.

 In other words, upon being asked to draw various parts of this website
 when zoomed, the driver is reporting that the hardware cannot accelerate
 the request, which causes a software fallback to happen. And there are too
 many operations on too many pixels (especially with the ongoing animations
 on that page) for this to happen smoothly on our hardware.

 XO-1.5 works better here because it does accelerate these operations.

 In order to decently accelerate this website we would need to implement
 all of the following acceleration paths in xf86-video-dove:

  1. Composite operations involving masks (even though there is unused mask
 handling code appearing in the later routines).
  2. Composite operations involving pictures with a bilinear filter
 applied.
  3. Composite operations involving a scaling transform.

 The graphics engine in the hardware should be capable of acceleration
 here, these are all quite primitive. In reality, it looks like the
 acceleration paths in the driver are quite incomplete and hence it rejects
 a hell of a lot of acceleration requests, we miss out on a lot of
 optimization all over (not just in Browse).

 Looking forward to the latest generation of the graphics driver that we
 have received but never successfully deployed ("vivante_exa"), all
 operations with masks are still rejected with a comment "If mask is on,
 fallback to sw path currently." There is no code that checks or handles
 the filter flag, so I guess item 2 is also in no better shape. As for
 transforms, vivante_exa does appear to identify scaling transforms
 ("stretch") so maybe that part does work. But without the other 2 items
 present, it is unlikely to mean much.

 I don't think this can be considered in scope for 13.2.0. I can't see a
 quick solution, and implementing the acceleration paths above would be a
 long and challenging project.

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