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 _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
