kwin/COMPOSITE_TODO

This file lists TODO items for the compositing code.

See file COMPOSITE_HOWTO for setting up kwin_composite.
See file HACKING for details on developing KWin, including building
    the kwin_composite branch.
See effects/howto.* for a HOWTO on writting effects.
See documentation in source (mainly in scene.cpp) for description
    of the design of the compositing framework.

TODO
=================================

* = not done, will be either done by me, or should be at least discussed first with me
+ = not done, I don't plan on doing it that soon
    - in other words, these should be the best ones for you if you want to help
! = like +, but they should be relatively simple
    - in other words, these should be the best if you want to get started with the code
/ = work in progress
? = should it be done?
% = should be probably done later, during cleanups and preparations for being stable


General TODO
=================================

? 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

* don't add workspace damage in Toplevel::addDamage()
    - instead add damage of windows to the screen only before doing the painting
    - this should prevent repaints because of changing obscured windows
*   - also, provide a call to just mark a window as needing repaint but not being damaged
        - this will prevent rebinding the pixmap or updating the texture
        - http://lists.kde.org/?l=kwin&m=116836151626848&w=2

* wait for decoration repaints
    - it is sometimes visible that the window contents are painted first and the decoration
        only afterwards with a small delay
    - maybe posted paint events need to be processed immediatelly, or maybe the compositing
        code should not update the window until the decoration is finished painting

! compile even without OpenGL or XRender
    - kwin_composite currently requires both OpenGL and XRender to build
    - compiling without either results in compile errors, needs to be fixed
!   - scene_xrender.cpp also requires XFixes
!   - check whether it compiles fine without XComposite/XDamage

? Expose events for overlay window - is it necessary to track it, like with root window?

% paint throttling
    - there's 5ms grace period per repaint to avoid overloading the system with just compositing
        and not letting the system do anything else - check and evaluate 

+ support for new window types from the wm spec for compositing
    - this will have to be done in Qt, kdecore and kwin

+ make effects configurable without having to recompile
    - possibly also add something like KWIN_COMPOSE for debugging purposes

* handle properly stacking order of deleted windows for showing in effects

* handle properly deleted windows that reappear (windowReadded() function?)

/ consider using an extra class for representing deleted windows
    - cleaning up Client/Unmanaged instances may still leave e.g. timers around if they're overlooked
    - an extra class could copy some interesting data and "replace" the old instance

+ Deleted::windowType() does not work


OpenGL 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
    - ATI - some (especially R200 chips) seem to work
    - I have absolutely no idea about other gfx cards, needs to be tested
        - intel
!           - does kwin_composite work there at all?
!           - does glcompmgr work there at all? (even with the various switches in the source)
+           - make kwin_composite work there if it doesn't
+       - 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 and there's AIGLX
    
+ AIGLX support
    - kind of works, needs more work
+   - it needs indirect rendering, should be autodetected and disabled somehow
%   - may require LIBGL_ALWAYS_INDIRECT set with older X.org
        (http://lists.kde.org/?l=kwin&m=116439615124838&w=2)
        (http://lists.freedesktop.org/archives/xorg/2006-December/020323.html)

! improved GLXFBConfig support
    - it seems a different config for each depth would be needed
    - from http://lists.freedesktop.org/archives/xorg/2006-July/016859.html and
        http://lists.freedesktop.org/archives/xorg/2006-July/017005.html it seems
        that some implementations have config support broken and glXChooseFBConfig()
        doesn't work with them properly
    - Compiz instead uses glXGetFBConfigs(), iterates over all configs and chooses
        the best one for every depth (code is in screen.c, search for "getFBConfigs")
!   - so most probably KWin should do similarly - get all configs, find the best
      one for the root window (or for the window used in the XComposite overlay)
      and the best one for every depth of drawables

/ GL_ARB_texture_rectangle vs GL_ARB_texture_non_power_of_two
%   - works; bugs in tfp_mode with power_of_two textures
        - ati (others?): power_of_two windows are drawn white unless non-tfp_mode
            is forced in findTextureTarget()

? 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

+ strict binding
    - there is code to support strict binding as required by AIGLX, but it's disabled, because
        copy_buffer in bindTexture() ensures strict binding as a side-effect
    - since copy_buffer hack should be removed in the future, strict binding will need to be enabled then
    - http://lists.kde.org/?l=kwin&m=116363084129170&w=2

% bindTexture() optimize copied areas
    - right now bindTexture() updates every damaged area and resets the window damage
    - it might make things faster to update only areas that need to be repainted
        and keep the rest damaged until needed

% clipping optimization
    - like XRender code has paintTransformedScreen(), avoid painting parts that are
        obscured (makes a difference with many windows open)
    - http://lists.kde.org/?l=kwin&m=116585618111882&w=2

+ shm mode needs support for more data formats than GL_BGRA in order to support e.g. 16bpp mode
    - http://www.xfree86.org/current/glTexImage2D.3.html


XRender TODO
==============================

+ SceneXrender::Window::performPaint() doesn't use saturation
+ SceneXrender::Window::performPaint() doesn't use brightness


Effects framework TODO
==============================

/ 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?
        - another problem is that then the window won't exist at all in the scene functions,
            so e.g. no paintWindow() will be called for it
?   - maybe just keep the object around in a special list

* more notification functions for effects are needed
    - currently there are only very few notification functions (windowAdded, windowActivated,...)
!   - virtual desktop change
!   - window state changes
    ? more

* shadows

* support for effects involving more virtual desktops
    - currently effects are limited to only the active virtual desktop

* support for grabbing input
    - during some more complicated effects, input (at least mouse) should be disabled,
        because currently there is no way to do input redirection

* pre-paint pass should be done completely before the paint pass
    - currently prePaintWindow() is done only after paintScreen() has already started,
        which means that if an effect sets PAINT_WINDOW_TRANSFORMED it needs to set it
        also in prePaintScreen()

* PAINT_WINDOW_DISABLED turning off from effects needs some utility functions
    - a window may have painting disabled for various reasons and their numbers may increase
        over time
        - so e.g. an effect showing minimized windows cannot simply turn off DISABLED
            for minimized windows, because it may be disabled also for other reasons
        - there should be some utility function that will be called by the effect
            with arguments saying which disabled windows it wants enabled


Effects TODO
===============================

+ adapt the kcontrol module used by Kompmgr
    - in kcmkwin/kwinoptions
!   - uses ~/.xcompmgr, convert to use normal KConfig
?   - I don't think these effects should be plugins or anything like that,
        probably simply write to kwinrc and use the Option class in KWin

+ implements all effects Kompmgr could do
+   - all effects from the Opacity tab should be already doable
!       - applying translucency only to the decoration
            - use clientSize() and clientPos() from Client
            - see also the alpha clear hack todo entry
!       - not usign ARGB visuals
            - just clear the alpha channel in the alpha clear hack
            - or do it while painting (see also the alpha clear hack todo entry)
!       - the rest - should be simple
*   - shadows
        - framework is not ready for them yet (see the todo entry)
+   - tab Effects
!       - fade-in should be simple
+       - fade between changes
            - will need notification about opacity changes
            - not sure if this is doable for other opacity changes then the ones
                initiated by the user or by the application
*       - fade-out needs framework for disappearing windows (see the todo entry)

+ minimize/shade effects
    - to replace the ones from KWin core
    - Client::animateMinimizeOrUnminimize()
    - Client::setShade()

/ zoom effect
    - enlarge a portion of the screen

+ logout effect
*   - should be triggered by ksmserver somehow

+ effects to replace widget effects (the ones in the Effects tab in "kcmshell style")
+   - needs support for new window types from the current draft of the EWMH WM spec
+       - needs patching Qt, netwm* classes in kdecore

/ showfps effect
    - for debugging, just shows transparent fps in some corner
    - just painting the number in paintScreen() should do, with glPushMatrix() and glLoadIdentity()
        to avoid all transformations
+   - needs bindPixmapToTexture() or something like that, for displaying the text
    - should also detect kwin being idle - it probably should detect in pre-paint that the only
        damage is its own area and avoid damaging for the next round in post-paint

+ debugpaint effect
    - should show what is damaged during each repaint step
    - probably just e.g. paint a red almost transparent area over damaged areas
    - needs special care to avoid causing infinite loops by its own damage (i.e. it damages
        part of screen to clear its own painting, that triggers itself again next repaint)

? other effects

+ EffectWindow should be completely opaque when kept as the only API for effects
    - no inlines, etc.

+ merge fadein and fadeout effects
    - so that they don't conflict and share the progress