You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
239 lines
11 KiB
239 lines
11 KiB
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 |
|
|
|
* 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 |
|
|
|
/ handle XRandr changes |
|
- output buffers and similar probably need recreating when the screen size changes |
|
|
|
! 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 |
|
|
|
|
|
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 |
|
- 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 |
|
|
|
+ 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 |
|
============================== |
|
|
|
/ design framework for graphical effects |
|
- modelling it after compiz seems to make a lot of sense |
|
|
|
* 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() |
|
|
|
|
|
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 |
|
! - would require adding xScale/yScale to ScreenPaintData |
|
- should be doable even for XRender |
|
|
|
+ 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
|
|
|