yukijoou/kwin
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kwin/COMPOSITE_TODO
Luboš Luňák 0283b97a62 When no transformations are needed simple screen painting can be used 
even for painting the whole screen, not just a region.


svn path=/branches/work/kwin_composite/; revision=605563
2006-11-17 08:43:24 +00:00

256 lines
12 KiB
Text
Raw Blame History

This file lists TODO items for the compositing code.
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?
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
! the opacity slider in the Alt+F3 menu doesn't work
- looks like the hack with adding custom widgets to popups no longer works
- it should probably be just changed to normal menu with reasonable opacity values
? Expose events for overlay window - is it necessary to track it, like with root window?
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
- I have absolutely no idea about other gfx cards, needs to be tested
- ati
! - 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
- 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
- no idea about this at all
+ - find out if it works
! 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
! - it seems that some systems (using older X.org?) will need local versions
of some #defines like GLX_TEXTURE_FORMAT_EXT
- Beryl has this code in beryl.h
! 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
+ 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
! 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
+ direct vs indirect rendering
+ - figure out when it is better to enable direct rendering (last argument to glXCreateNewContext())
and figure out how to turn it on safely
+ 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
XRender TODO
==============================
+ 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)
+ 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
Reference in a new issue View git blame Copy permalink