266 lines
12 KiB
Text
266 lines
12 KiB
Text
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
|
|
- nvidia: tfp_target needed in bindTexture() else glXCreatePixmap fails;
|
|
shouldn't be necessary according to texture_from_pixmap spec
|
|
- 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
|
|
|
|
|
|
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
|