diff options
authorKristian Lyngstøl <kristian@albus.(none)>2007-08-27 09:23:47 +0200
committerKristian Lyngstøl <kristian@albus.(none)>2007-08-27 09:23:47 +0200
commit2871e6f23e0a097d3450b2d85443a85481ccf340 (patch)
parent98125317db9f37b607e09fa9e53417bd9465a3f2 (diff)
Remove Beryl HACKING file
1 files changed, 0 insertions, 95 deletions
diff --git a/HACKING b/HACKING
deleted file mode 100644
index 685ee6b..0000000
+++ /dev/null
@@ -1,95 +0,0 @@
-Tips and pointers (*berylhackingtips):
-* A very small portion of beryl is the actual OpenGL magic, most of working
- with plugins is manipulating the main data structures (CompScreen,
- CompWindow) and working with Callbacks, core is a different beast.
- Appropriate data structures are more important than impressive algorithms!
-* IPCS can be used for communication between plugins see
- beryl-core/src/ipcs.c and Cube/Rotate for good examples. Avoid use of this
- however as it is both slow and ties plugins together in ways you may not
- wish.
-* Premature optimization is the root of all evil, profile before needlessly
- wasting time on optimization. To profile beryl you can compile with -pg
- (CFLAGS="-pg" ./configure; make; blabla) and when beryl exits it drops a
- 'gmon.out' in it's working directory. From that directory run gprof
- /path/to/beryl/executable > berylprof, and you can view the profile in a
- text editor, or a profile tool such as kprof (highly recommended).
-* WRAP/UNWRAP works a bit like a stack of sorts, examine a backtrace from gdb
- to make things clear. This is relatively inflexible and ideas for
- improvement post 0.2.0 are welcome.
-* Beryl can be debugged without crashing your system, compile with debugging
- symbols (-g) and run in a tty with gdb beryl, set breakpoints with 'break
- function' run with 'run' when X freezes because of the break use
- alt+sysrq+r then ctrl+alt+f1 to get to the tty, examine things, and
- continue execution.
-* Tieing things whether it be plugins, settings/core, or settings/an
- individual plugin is bad and should be avoided. 'Write (programs) to do one
- thing and do it well'.
-* As a rule avoid pixel shaders as they aren't exposed by AIGLX as of
- current. Ala water.
-* Plugins should work within core, at the same time changes to core can be
- made to accomadate a specific feature such as transparent cube.
-* Optimizations are always welcome, benchmark isn't horribly accurate but if
- you consistently notice a ~10-20 FPS improvement, or a decrease in lag
- spikes , or something that's not '1 FPS more when rotating cube left' go
- ahead and commit it, worst case is it's reverted. Things to look at:
- Switcher, particle system in animation, input enabled zoom.
-* A keybinding to replace windows (run through placement algorithm again)
- would be an easy to implement and useful feature. Bonus points if the
- windows fly to their new positions.
-* Comment code! not only does this help everyone in their tasks it helps you
- learn the codebase, pretty easy to do.
-* Allow annotate to draw directly on to the window texture. This would involve
- procing drawWindowTexture as in beryl-plugins/src/neg.c and binding an
- opengl rendering context to the windows GLXPixmap, beyond that it's pretty
- similar to the rest of annotate.
-* Improve plugin short descriptions, maybe make long descriptions a bit more
- wordy as well as they are being moved to tooltips.
-* Anyway to speed up IPCS?
-* Refactor some of the code in place, it's spaghetti code as it stands.
-* Exempt specific windows from window decorations as part of the emerald menu.
- Remember this setting for windows? look at all kwin has for stuff like this,
- duplicating a small amount would be nice.
-* Contribute to I18N
-* Work on kberylsettings the PyQT settings manager in branches.
-* Add CompOptionFont to settings
-* Look for functions that can be inlined. use __attribute__((always_inline)) to
- force the inline even without -finline-functions
-* Look at using LIKELY/UNLIKELY macros for if/else statements in tight loops
- with a high discrimination towards one or the other. Profile to find such
- areas, premature optimization is bad.
-* Participate in discussion and planning on IRC, it's invaluable. Make yourself
- a part of the beryl development community rather than a lone wolf.
-* Take lengthy discussions on the mailinglist.
-* Add more code documentation in Documentation/ about interfaces used by Beryl.
-* Look in Documentation/TODO-Multiscreen for multiscreen bugs to fix during
- 0.3.x
-* Add more stuff here!