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