- Replace signal/slot by timerEvent:
nobrainer - signal/slot has a CPU overhead and at least one event cycle delay

- General change in the vblank strategy + fix sync bug:
The present implementation has a bug which causes an (unintended) repaint at max 1ms delay. This is fixed.
Also kwin now tries to avoid calling glXWaitVideoSync, because it blocks and -while costs nothing- steals the cpu time from other operations (notice that currently kwin tries to slot 10ms ahead of the next estimated sync, since painting usually takes up two 2ms that means we're loosing 8ms from a 16ms timeframe (60Hz, integer division...), because of the bug, you'll actually wait 14-15 ms...) by just waiting for the screen.
The present estimation isn't perfect and could be improved by bitshifting up the interval for more precision. Nevertheless you get hardly any tearing this way.

- Introduction of com_maxfps... err... "MaxFPS"
I took the opportunity to separate the target refreshrate from the screen vblank interval since there's no point in updating the content up to 100Hz (doesn't happen? play 3 videos at once and have a little bad luck - X11 isn't synced ;-) just because your screen can do.
It defaults to "35Hz" what i consider a sane value for a Desktop (it's no shooter...),

- BUT (remaining issue)
This exposed a general problem with compositing which i first thought to be tearing (from tests with two glXWaitVideoSync calls, my nvidia GPU waits the proper time amount for the vblank, so there is no "tearing with vsync & nvidia" - but this one...)
It's very present if you play a video (eg. 23.976Hz) with mplayer which prints to konsole at about 50Hz (...) and have the (tear prone) video intersecting and above the mplayer output.

You'll see "tearing blocks" in the high frequent konsole area of the video window.
>From what i can say this seems to be caused by the texture bound to the video being updated "immediately" and ahead of the damageNotify event and gets painted in "dirty" with the konsole update.

I've tried to compensate this by marking the actual "dirty" area in paintSimpleScreen but that oc. doesn't work for translucent windows (and caused much more region calculations - huh)

For the moment this could be worked around by simply raising MaxFPS (ie. get closer to the current behaviour) but it would be better to prevent this in the first place and have the damage area match the actual texture update.