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

List:       kwin
Subject:    Re: Compositing manager
From:       Thomas =?iso-8859-1?q?L=FCbking?= <thomas.luebking () web ! de>
Date:       2006-07-16 17:22:02
Message-ID: 200607161922.03137.thomas.luebking () web ! de
[Download RAW message or body]

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 ;)

> 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 ;)

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.

X is damn slow on pixmaps, due to the CPU involvement (to my suspection, there 
may be other problems) - 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)

Thomas
-- 
Fear... Fear attracts the fearfull.
The strong. The weak. The innocent. The corrupt.
Fear... Fear is my ally!
_______________________________________________
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]