[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: GetFBConfigs
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2007-01-27 19:11:01
Message-ID: 200701272011.01400.l.lunak () suse ! cz
[Download RAW message or body]

On Saturday 27 January 2007 19:20, Philip Falkner wrote:
> On Saturday 27 January 2007 09:45, Lubos Lunak wrote:
> > On Saturday 27 January 2007 01:25, Philip Falkner wrote:
> >
> >  Do you mean that sorting by caveat helps you with a problem or causes
> > it? I'd certainly prefer avoiding configs with caveats, as they are,
> > well, caveats.
>
> Without the caveat sort, it chooses one particular config for drawables
> (0x32) which is the last 24-bit config in my list, and is "slow".  This
> works for tfp and shm, but in fallback when it tries to make ctxdrawable
> current, X crashes.  This doesn't happen with any other configs, even other
> slow ones.

 I see. Then I'd sort by caveat and later turn it off, if it will ever 
actually matter in practice.

> > - tfp_bind_to_rgba is per FBConfig, so I think it should not be just
> > global. Compiz has one setting per depth. The same actually should apply
> > to texture_y_inverted now that there are more than one config.
>
> It's only the 32-bit config that can ever possibly have
> BIND_TO_TEXTURE_RGBA, so a global flag was sufficient to indicate it.

 Ah ... ok :) .

> As for texture_y_inverted, the way we get that currently
> (glXGetFBConfigAttrib) works, and doesn't require a round-trip.

 Although unlikely, I think texture_y_inverted could be different for 
different depths. And we only have a global flag that is later used in 
performPaint().

>
> > - I'm also not quite sure about using just one ctxdrawable. Compiz uses
> > just one because it uses only TFP, so it doesn't need more, and just
> > because Beryl uses just one with SHM doesn't necessarily mean it's
> > correct. IIRC you added the second context because there were some
> > problems, but I don't remember the details anymore and can't find the
> > right mail. Or is this what the "this may not work" debug is about?
>
> I don't especially see why we'd need further contexts for shm, but then I
> don't understand that code too well.

 My mistake, shm does not use extra context, so this is only about fallback.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak@suse.cz , l.lunak@kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz
_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]