EXA patches

Michel Dänzer michel at daenzer.net
Tue Aug 4 03:27:39 PDT 2009


On Tue, 2009-08-04 at 09:35 +1000, Ben Skeggs wrote:
> On Tue, 2009-08-04 at 01:29 +0200, Maarten Maathuis wrote:
> > 2009/8/4 Maarten Maathuis <madman2003 at gmail.com>:
> > > I think glyphs are uploaded through UTS when possible, so that might
> > > just be it. In the case of driver pixmaps it would composite them from
> > > whatever driver pixmap you have iirc.

I wonder if the slowdown could be due to malloc()/free() of
pExaPixmap->sys_ptr memory which is never used. Would it be hard to fix
that so it's only allocated when it's really needed?

> > > I will make another patch handling exaGetDriverPrivate more gracefully.
> > 
> > This seems to give many issues (calls to exaGetPixmapDriverPrivate
> > converting a pixmap to driver pixmap in random places).
> > 
> > Personally i'm inclined to go with a new exa call that forces a pixmap
> > into the driver, simple and less problematic. This could be called
> > after dri2 pixmap creation (which is a seperate function iirc).
> It seems to me that exaMoveInPixmap() is probably a good call to use
> here.  Just state that a driver using mixed-mode must call it before
> attempting to access a pixmap from outside of functions called by EXA. 
> 
> It's what drivers had to do with "classic" EXA from Xv etc, so it seems
> to make sense to keep that behaviour.

That could work, if exaMoveInPixmap did the right thing.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer


More information about the xorg-devel mailing list