Window procedures in ScreenRec not populated by DDX driver. why?

[Adam Jackson]

On Feb 15, 2011, at 9:08 PM, kumar vemuri wrote:

> Hi Pauli,
> 
> But some window procedures like the window painting procedures
> (ClearToBackground, CopyWindow and compositing) can be accelerated by
> hardware. 
> a. Shouldnt these procedures be implemented by the driver (to get hw
> acceleration for these procedures)? 
> b. Most of the driver implementations dont implement these window
> painting functions. Any reasons for this? 

The default implementation of those procedures are implemented in terms of
other screen and GC paths that the drivers _do_ accelerate.  You're free to
implement your own, if you like, but that's only worthwhile if the result is
actually faster.

For example, miClearToBackground calls ->WindowExposures (usually
miWindowExposures), which calls miPaintWindow, which calls pGC->PolyFillRect.
So if you implement that last one - and all the extant acceleration
architectures do - then you have accelerated background clears.  More
importantly, all the _other_ logic required by a background clear, like
computing and sending the exposure events, is handled by common code, and is
therefore not something your driver can get wrong.

- ajax