[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 20:26:02
Message-ID: 200701271526.02416.philip.falkner () gmail ! com
[Download RAW message or body]

On Saturday 27 January 2007 14:11, Lubos Lunak wrote:
> On Saturday 27 January 2007 19:20, Philip Falkner wrote:
> > On Saturday 27 January 2007 09:45, Lubos Lunak wrote:

> > 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.

Okay.

> > 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().

Yes, but glXGetFBConfigAttrib() will query fbcdrawable[toplevel->depth()], and 
since texture_y_inverted is stored in Window, different windows with 
different depths could happily have different y-inversions, couldn't they?

Nonetheless, I've altered the patch to add an object in SceneOpenGL which 
contains fbconfig, bind_texture_format, and y_inverted, all set in 
initFBConfigs().  texture_y_inverted still exists and is used the same way in 
shm and fallback; for tfp, it's set to fbcdrawableinfo[depth].y_inverted.  It 
may not be any better, but it is a little cleaner-looking.

> > > - 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?

Well, I tried the one ctxdrawable per depth for fallback, and it made little 
practical difference.  Fallback is still crashing X when the context moves 
from 32 to 24.  24 to 32 is fine, as is 24-24 and 32-32.  The X log backtrace 
suggests the crash happens when resizing a framebuffer while making 
ctxdrawable[24] current.
Perhaps what we could do is always use the highest depth available, and any 
windows using anything else get their pixmap's depth altered, perhaps with a 
copy_buffer-like mechanism.  We could use this in tfp, too, for when there's 
no fbconfig for that window depth.  However, I have no idea how to do this, 
or even if it would fix the fallback problems.

Another possibility would be to simply fail in fallback for all non-default 
depth windows, and in tfp for all un-available window depths, leaving the 
window unbound.


I also looked at a 16-bit X server, and my config list is changed to mostly 
16s, with one 32.  And more of them are slow.  Still, tfp and fallback work 
exactly as they do in 24-bit mode, so that's okay.  Shm is broken, however, 
with 16-bit windows (see attached), though it produced no visible error 
messages.  32-bit windows are still fine.

-- 
Philip Falkner

["shm-16.png" (image/png)]

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