kwin/COMPOSITE_TODO

* = not done
/ = work in progress
? = should it be done?

See the HACKING file for KWin details. The composite-related sources are mostly
composite.cpp and scene_opengl.cpp (TODO: add comments and general overview).

Sources:

- glcompmgr : http://lists.freedesktop.org/archives/xorg/2006-July/017006.html ,
              http://www.mail-archive.com/compiz%40lists.freedesktop.org/msg00023.html
    - simple and easy to understand
    - works even without texture_from_pixmap extension
    - claims to support several different gfx cards
- compiz : git clone git://anongit.freedesktop.org/git/xorg/app/compiz
    - the ultimate <whatever>
    - glxcompmgr : git clone git://anongit.freedesktop.org/git/xorg/app/glxcompgr
        - a rather old version of compiz, but also simpler and as such simpler
            to understand
- libcm (metacity) : cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co libcm
    - no idea about it
    
- http://opengl.org - documentation - OpenGL Redbook, GLX docs, extensions docs

TODO:

* Check/make it work with other gfx cards
    - I've tested only with nvidia with the 9625 beta drivers and 8776 stable drivers so far
    - I have absolutely no idea about other gfx cards, needs to be tested
        * ati
        * intel
        * who knows what else

? Xgl support
    - Compiz itself doesn't work when compiled with the libGL from nvidia,
        it ships its own and links against it
    ? might be worth trying to use that libGL as well
    - it may be just because of the special libGL, but when testing with Xgl
        it even seemed non-conformant - none of the provided configs had
        GLX_RENDER_TYPE with GLX_RGBA_BIT even though required by GLX
        and other funny things. Indeed, it may be just me being still pretty
        clueless about these things.
    * is there a good reason to support Xgl? With the 9625 nvidia drivers
        it seems to work fine without them
        
? AIGLX support
    - no idea about this at all
    * find out if it works

* XComposite overlay window
    - X.Org 7.1 and newer have XComposite extension version 0.3, which allows
        creating an overlay window to paint to instead of painting to the root window
    - I still run older X.Org here
    - the code in glcompmgr for this is in HAVE_OVERLAYS, stealing primarily from
        here should be better since it's simpler and the code so far has been
        modelled more after glcompmgr
    - the code in compiz for this is in USE_COW
    * use double-buffering with the overlay window - kwin already has code
        for double-buffered destination drawable, but I haven't been able to test it

* when relying on extensions, detect that they are available
    - some of the glcompmgr code probably depends on OpenGL/GLX extensions that may
        not be always available, probably the same with compiz
    * find out which code relies on extensions and add checks

? alpha clear hack
    * find out if it affects performance
    * if yes, try to find a better way of solving the problem
    - since kompmgr has an option to make only the decoration transparent,
        it should be possible to do the same here - if the window has alpha and a decoration
        or if there should be only the decoration transparent, paint first the contents
        and then the decoration - this should make it possible to paint the decoration
        without the random alpha that is right now handled by the alpha hack

/ design framework for graphical effects
    - modelling it after compiz seems to make a lot of sense

* update only those parts of the screen that have been changed
    - for paintSimpleScreen() - it currently sets region to the whole screen
    * instead of using glXSwapBuffers() there should be glCopyPixels() used
        - compiz has such code in evenLoop() in the if() block for COMP_SCREEN_DAMAGE_REGION_MASK
        * perhaps syncing to vblank will be needed to avoid flicker
    * XCopyArea() should not update the whole screen but only the affected areas

* sync to vblank
    - currently the compositing code is run with 20ms timer, i.e. constant 50fps
    - the GLX_SGI_video_sync extension should be used
    - compiz uses this, no idea about it though

? GL_ARB_texture_rectangle vs GL_ARB_texture_non_power_of_two
    - code currently uses GL_ARB_texture_rectangle (GL_TEXTURE_RECTANGLE_ARB), using
        normal textures when GL_ARB_texture_non_power_of_two is available should(?) be
        preferred

? in SceneOpenGL::bindTexture() with tfp_mode, with some gfx cards it seems
    to be faster to not short-circuit the texture binding when there's been
    no damage
    * confirm and try to find out when to do it and when not

* SceneXrender::Window::performPaint() doesn't use xScale/yScale
    - XRenderSetPictureTransform() should be capable of doing this
    - note that the matrix used seems to be weird (it doesn't act like the normal transformation
        matrix as far as I can tell)

* solve somehow disappearing windows
    - i.e. when a window is e.g. closed, the Client/Unmanaged object is destroyed, but animations
        should be going on
    ? maybe animations could be done actually before the state change, it makes sense to destroy
        the window only after it's finished exploding or really minimizing the window only after
        the animation of minimizing to the taskbar is done, however this looks very hairy
        and error-prone
    ? maybe the animation effects should keep the necessary info themselves, so that the object
        can be destroyed
        - the problem here may be what to do when the window again reappears, a new object will
            be created, but the old animation should be stopped - compare window id's?
    ? maybe just keep the object around in a special list

* add a postpaint pass
    - needed for animations to trigger next repaint, currently window damage is reset after
        the painting pass, meaning the damage cannot be added from there
    - current workaround is to damage the whole screen, as there's a for resetting that damage
        in advance