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

List:       kwin
Subject:    Re: Compositing manager
From:       Zack Rusin <zack () kde ! org>
Date:       2006-07-20 12:49:40
Message-ID: 190401011420.07877.zack () kde ! org
[Download RAW message or body]

On Sunday 16 July 2006 19:22, Thomas Lübking wrote:
> Am Samstag, 15. Juli 2006 23:19 schrieb Matias Valdenegro T.:
> > Interesting, any idea on how to overcome this problem?
>
> none? (as long as X handles all pixmaps through the CPU, maybe some
> shared MEM extension (like the MIT one) could allow to write an X
> server that avoids this, ask nVidias/ATI ;)

I'm not sure what you mean when you say "pixmaps through the CPU" but 
it's either way not correct. Pixmaps are stored in vram when available. 
Thanks to AGP gart they're being swapped out to agp memory when there's 
not enough space for them.


> > And BTW, how the hell does the Pixmap gets converted to a Texture
> > without using GLX_EXT_texture_from_pixmap?
>
> there was (and is) a glcompmgr posted on the XOrg list that afaik
> doesn't use it, but i don't know how and this probably won't make
> things faster ;)

To create a texture from a pixmap, you fetch the contents of a pixmap 
and push that contents back again as a texture. 

> However, i don't ask for a way without calling the extension, but an
> X server that internally allready operates on textures and the GL
> buffer (so on openGL you paint on the offscreen buffer and use
> glCopyTexImage to update the texture)
>
> On such server, GLX_EXT_texture_from_pixmap would just answer the id
> of the texture for local use and create a real pixmap for foreign
> (network, real protocol) use, where the conversion is the least of
> your problems.

That's not really a problem. Blits within vram are insanely fast. 

> X is damn slow on pixmaps, due to the CPU involvement (to my
> suspection, there may be other problems) 

Nope, that's not the case. It's a whole different issue.

> - e.g. compare moving a 
> (huge, or use a profiler) widget with a (huge as well) pixmap as
> background with one filled with a plain color (what's accelerated by
> the server) and than compare with moving a huge texture in a 3D
> environment (also accelerated), best using overlay... or fill a
> (huge, and best with a lot of clipping ;)  area with a pixmap brush
> (or the gradient brush, at least without XRender acceleration)

That's comparing apple's and orange's. Remember that the moves as you 
described involve a whole lot of more from the server than moving a 
texture in an OpenGL app.

z

-- 
The word "woman" is no longer politically correct.
You should use "Female-American" instead.

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