From kwin Sat Jan 27 19:11:01 2007 From: Lubos Lunak Date: Sat, 27 Jan 2007 19:11:01 +0000 To: kwin Subject: Re: GetFBConfigs Message-Id: <200701272011.01400.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kwin&m=116992516719372 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