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

List:       kwin
Subject:    Re: GetFBConfigs
From:       Philip Falkner <philip.falkner () gmail ! com>
Date:       2007-01-27 18:20:59
Message-ID: 200701271320.59682.philip.falkner () gmail ! com
[Download RAW message or body]

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.

BTW, slow here corresponds with having an accumulation buffer; it could be 
that it's only that buffer which is actually slow, which would explain why I 
see no performance difference.

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

Having said that, if you want these stored per depth, okay. :)

> - 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.  It may be a good idea to have more than 
one ctxdrawable for fallback, though; currently, fallback will fail rather 
spectacularly if a window isn't the default depth.  I tried fdclock -sta, and 
the whole screen went black.  Trying to switch focus back to the terminal 
then crashed X. :)

The reason for ctxdrawable being long-lived was a memory leak in X, so 
creating the right context on the fly won't work so well.  I can certainly 
try having additional long-lived ctxdrawables per depth.

> - On the other hand, I'm unable to get config for any other depth than the
> default and 32, with either nv or nvidia driver. Can you get more depths?

All but one of my configs are depth 24, with one 32.  All the glxinfo config 
lists I could find for various drivers were either all 24 (fglrx), or 
combined 24 and 32.  Taking down the X server depth to 16 or less may affect 
this.

-- 
Philip Falkner
_______________________________________________
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]