Further information/clarification:
By video tearing I mean: video played in any media player (including flash but that's a different beast entirely!), I get horrible sync/refresh patterns of part of the screen updating before the rest, which splits the frame randomly in 2 or 3 or more places. High motion scenes are especially unbearable. Xv was the driver of choice. X11 actually worked better (more smoothness and less framedrop/jumpiness in all players) but X11 always tears anyway since it's not accelerated and thus doesn't address the problem. 

With desktop effects disabled, all is well with video and xv. 
With compiz enabled, when in fullscreen, despite what could be the tiniest bit of "jerkiness" there is absolutely no tearing. The video playback, while not as flawless as without desktop effects enabled, is still darn close. If it's at all important, compiz with the same level of bling (transparent cube, wobbly windows which become transparent when moved, etc) is at least twice as fast as kwin's effects on my card.

is the problem only in 4.3 or also in 4.2? If it is in 4.3 can you try a recent checkout (e.g. nightly packages).

Personal remark: When there is the combination of intel and Ubuntu 9.04 I doubt that the problem is in kwin.

seems the Ubuntu workaround for compiz includes
a) disabling VSync
b) skip fullscreen unredirection
you can set a) in the advanced section but it seems there's no gui config for b) so edit ~/.kde/share/config/kwinrc find the [Compositin] section and add a key

UnredirectFullscreen=false

then call (e.g. from a textshell)
qdbus org.kde.kwin /KWin reconfigure

about general speed issues:
tried to change the texture generation (shm vs. tfp) and dri usage (on/off)

Personal remark: (this is fun)
"Fast" is not exactly the term i'd use in combination with intel "GPU's" at all ;-P

"seems the Ubuntu workaround for compiz includes
a) disabling VSync
b) skip fullscreen unredirection"

--
I don't know where you're getting that, but compiz works perfectly with and without vsync, and undirection does indeed help (though "tearing" doesn't happen either way. Undirection only helps certain players with smooth playback). I just tried both of those options with compiz to confirm. I wanted to clarify this before I go rooting around in KDE's guts with the config you posted.

As I suspected, the config you posted not only causes it to tear, but also to make video playback very choppy.

VSync has no effect one way or another with either Kwin or compiz (though that's a good thing with compiz). 

Disabling unredirection caused considerable choppiness (and the tearing remains).

Also, effects are consistently slow with Kwin. They are smooth as butter in compiz with Atom CPU at 800mhz, and there is no video tearing with any setting (though ENABLING unredirection, which is the default setting, improves playback fps on hi-res content).

just googled, (pretty much at the end of method 2)
http://www.ubuntugeek.com/intel-graphics-performance-guide-for-ubuntu-904-jaunty-users.html

skipping unredirection to improve the performance /is/ weird, but who knows...

w/o vsyncing you'll get tearing - with any... thing (maybe the compiz setting is just w/o function or the intel driver is even buggier than anyone thought) unless your app accidently makes the same fps as your monitor 

now speed:
so... what are your settings about texture generation and direct rendering?

I don't know who wrote that guide or the logic behind it, but after cycling through 4 sets of drivers (2.6.3, 2.7.0, 2.7.1, 2.7.99.1) and every option combination I could get my head around, I can say with confidence that's not the case here. I honestly don't know what they could be thinking by disabling undirection. Also, hacking videoram into your xorg? That's sheer insanity--if they wanted to fix the mtrr, that's the way to go, not to hack it into xorg. 

Anyway. I did try with all kwin combinations of direct rendering, vsync, rendering method ('fallback' causes major crashing by the way), to no avail. The combination I settled on (no vsync, direct rendering, pixmap) is the fastest here, but still ages behind compiz. It's not unbearably slow, just "intel slow." Hope compiz manages to be so bloody fast, even with 2 videos playing and the cube rotating, is beyond me. 

Again, the sync to vblank has no effect in either kwin or compiz. But in compiz there's no tearing. 

Intel issue? 

PS: UXA is still buggy. I'm using EXA greedy, which is faster.

maybe intel currently doesn't support vsync at all (and the higher compiz fps shadow this)

i assume you tried
- tested deactivating all visual FX in kwin (ruling out some broken plugin impact, at least 4.3b has/had a known repaint bug in the slide back module) and
- set "keep window thumbnails" to never
- set texture filter to "nearest"
but what if you 
- hide the decos (alt+f3 -> advanced, 4.3b also had a known bug on window activation)

moreover, to get a more precise idea on performance: what does hit your fps?
- video playing (which should be captured by dri)
- window activation? (see above)
- T&L? (like in cover switch or present windows)
- blurring? (turn it off...)
- some particular effect? (the cube...)
- large screen updates (e.g. scrolling in konqueror/firefox - app related?)

then (just to be sure):
when testing compiz, do you run KDE as well? (i.e. ensure no other process whether app or daemon sucks away your resources)

Okay, here's what I did:

A. Desktop Effects

1. Under tab "General"
[Checked Enable Desktop Effects, Compositing is active]
- Unchecked Improved Window Management
- Unchecked Shadows
- Unchecked Various Animations

2. Under tab "All Effects"
- Unchecked [everything]

3. Under tab "Advanced"
[Compositing type: OpenGL]
- Keep window thumbnails: Never
- Checked Disable functionality checks
[OpenGL mode: Texture From Pixmap]
- Texture filter: Nearest (fastest)
- Checked Enable direct rendering
- Unchecked Use VSync
- Unchecked Smooth scaling (slower)

B. Multiple Dekstops
- Number of Desktops: 4
[Standard names: Desktop 1, Desktop 2, Desktop 3, Desktop 4]

C. Screen Edges
- All corners set to "No Action"
- Switch Desktop on Edge: Disabled

D. Screen Saver: Blank Screen [Start automatically: 15 minutes]
E. Launch Feedback: [untouched]

Hit Apply. Logout. Restarted X Server. Login. Entered password.
Here's what happened:
The KDE loading screen showed up, with the icons fading into view. Around the icon with the wrench and screwdriver, the screen flickers to blank for about a second and a half, and then flickers back to the loading, where it had already made it to the desktop icon's fading. The big K icon fades in, then the desktop appears with the computer intro noise. My widgets load. 

I double click "Home" from my desktop folder (I have clicking set to "double-click activation" btw), and verify that it launches without any effects. There are no shadows no transparency, no cube, nothing. I then browse to my SD card's video directory and double-click on my test video. The icon for dragon player appears next to the cursor (launch feedback), but it's all jittery, and it leaves motion trails as it bounces. Very unsightly. 

Dragon Player opens with the video. I drag the slider all the way to the beginning, then press play, watch for a bit, then double-click the video window for fullscreen. Voila. Immense choppiness and tearing in both windowed and fullscreen. The "launch feedback" icon, as I mentioned was also misbehaving, leaving motion trails and corruption when it jumped. 

I double-clicked to show the normal player, then did F3->Advanced->No Border. I get a message about needing to use Alt+F3, so I pressed OK and tried it again in both windowed and fullscreen. Same tearing and choppiness. I exited Dragon Player with Alt+F4. I reloaded Dragon Player...and all my sliders and buttons were gone, even though the borders were back. Oh boy. Settings->Configure Toolbars shows that they should still be there. Time to file another bug... XD

I'll do the second part of your post now. I hope I can fix my Dragon Player though, or else I won't be able to rewind to try again...

One other point of note, really quickly:
On my sister's computer [NVIDIA 6xxx with 180.XX driver], similar tearing problem (KDE 4.2.2, 4.2.3), regardless of direct rendering/vsync, etc. Problem disappears with compiz when "Sync to VBlank" is enabled.

In her case, though, there's no choppiness anywhere, for anything. It's all buttery smooth with any setting or DE, but video tearing happens only with kwin. I heard about 'the latest NVIDIA drivers (184.04+ or something) will "fix all tearing issues, wherever they arise!" but that's a different story. Right now I'm only concerned about mine working, but thought it worth mention that hers had the same problem that was alleviated with compiz. (She liked kwin better though despite the tearing...as do I). ;)

Oh, this is very interesting. When I hit "Suspend Compositing", the video plays back [almost] exactly like it did with compiz--no tearing... but I assume that's just like disabling desktop effects, since, well...that's what it does. Also, the launch feedback problem also disappears. 

Anyway, FPS!

- When idling (same setup as before, but with the Desktop Cube and Show FPS enabled), FPS~40. It dipped as low as 29 and as high as 44. 
- With desktop cube activated (no spinning, I just pressed Ctrl+F11), FPS~17. The only window I have open is the Desktop Effects - System Settings window I just came from. 
- Once I exited from the desktop cube, the FPS went back to around 40, but fluctuated madly from 40 to 57. It fluctuates in regular cycles, and the period seems to be 1 second. The graph goes from green to yellow to green to yellow every second. Intrigued, I pressed Alt+F2 to see if there were any processes taking up CPU: just Xorg (25%), kwin (10%), krunner (5%), plasma=desktop (2%). While I was looking at this chart, the FPS stabilized around 40 again: graph was pure yellow interspersed by a few red peaks and a rare green valley.

Then I closed everything and went straight to the desktop. FPS=100, graph is just green with a few red peaks. Folder view peeking: with many layers open and the new Air plamsa theme, with an image preview displayed, the FPS was about 65. Back to plain desktop: 100FPS. Desktop cube from plain desktop: ~20FPS. 

In dolphin in my movies folder, fluctuated from 40 to 60 again, one fluctuation per second roughly, but a bit more erratic. Graph shows alternating patterns of green, yellow, some red peaks, green, yellow, some red peaks, etc. When a video was selected and played in dolphin's preview, FPS stabilized to around 55FPS. 

In dragon player (windowed) around 40fps. Fullscreen: 15-25FPS (seems a bit choppier than it was before, likely because of the FPS meter in the corner), tearing still present. 

Cover switch with one instance of dolphin (home) and system settings: 39FPS (idle), or 32FPS (Alt+tab held down for switching). Tried with 2 instances of dolphin+Desktop Effects and I got the most horrendous artifacts in the background (and Kscreenshot is buggy as hell and tried to take hundreds of screenshots when I only pressed Prnt Scrn once during the animation to show you), then I had to ctrl+alt+backspace to force logout (system became unusable after the kajillionth instance of Kscreenshot showed up).  Screenshot attached (I think it's the FPS graph/meter's fault; this doesn't happen normally).

(While logging back in, I noted that the FPS meter shows 100FPS while logging in until the desktop is partially shown as a checkered background when it's 40FPS, then soon gets back to 100FPS again and the background is restored).

Scrolling in Konqueror: (more motion artifacts with the launch feedback), around 45FPS on a google search of "KDE 4.3" showing 100 results per page; scrolled with the down arrow. When idling at bottom of page FPS goes from 80 to 95. This is a lot better than with any other window I've tried so far (dolphin, system settings, etc). 

I hope this was illustrative. I'm going to see about getting compiz's framerates for comparison.
Using compiz with KDE: of course.

nvidia-settings provide a global option for vsyncing (for GL and even XVideo, works here...) so there should not be any tearing with any application ever (even the lousiest written... by me... mini opengl stuff is catched)

...
....
..... (*me thinks*) ... ... .. .
$%&/&%$/$&////!!!!!

ok, i can CONFIRM that kwin's vsync switch is NOT related to the video output at all, but just to kwins repaint cycle
instead the nvidia driver was so kind to activate global syncing for me.

(gnarf! who had the great idea to name some "cap fps to screen refresh rate" to "vsync"? that's really not the same... na ja, schwamm d'rüber)

- a tool called driconf should help you on the tearing issue then.
- kwin needs a bugfix for either activating GL vsync or rename that switch
- you should nevertheless activate kwin's "vsync" as this will prevent it from performing insanely many repaint cycles that will sooner or later suck the rest out of your not so mighty CPU (e.g. when running glxgears)

if this works, please test "top" on sth. like glxgears (which now should NOT perform over your monitor refresh rate and should be on the top of the top list, NOT kwin)

in addition this just ended inbox
#177495
#184059

but i think unredirecting works fine here... as long as the fullscreen app uses the same resolution as the desktop (tried lowering res in quake2 ! fps usually stable at monitor refresh dropped to 40-60...) and i can actually see the window gets (un)redirected regarding popups

personal sidenote at the:
w/o wanting to insult the phonon team i suggest to use Xine or MPlayer or some direct FE (e.g. smplayer is a neat Qt4 FE for mplayer...)

mid air, so on #11
yeah, suspending is just "no compositing" fps in general look ok (for an intel chip) and should except fs video be sufficient but the fs video cannot have been unredirected with the fps meter active (i.e. the unredirection did not apply, the fps counter vanishes here if i trigger a fs window)

Which NVIDIA driver are you using? Post-180.x? I did hear that the newer driver does a global sync, which is sheer awesomeness. I never tried it though; just stuck to the crap 180.X driver Kubuntu recommended. But anyway, back to me. :)

So I got that driconf program from the Jaunty repos. Now if only I had a clue what to do with it. I assume I'd select "always synchronize with vertical refresh" for the "synchronization with vertical refresh swap interval" option? 

Or should I input something into the "advanced" mode?  
Also, do I need to restart X (I assume I would have to do so)?

Okay, I'll keep VSync on in the kwin options and fiddle around with this tool. I agree that kwin should offer settings to do a real OpenGL VSync for all applications (like video), and also rename the existing option.

185.15 (beta), do a great job on TFP here but the global vsync'ing has been available for several versions (including the 180ies)... maybe only through coolbits, though. dunno. (Option "Coolbits" "1" in section device)

actually (and after looking into the code...) i probably need to row back with this little rant.

it very much looks like kwin compositing /has/ working vsync (with glFlush(), glXSwapBuffers, glXGetVideoSyncSGI and all) but this does not affect other apps (which like glxgears in consequence paint as much as they can) - even on indirect rendering. (what i falsely took as "kwin's vsync is not working")
but it should apply to your visual experience unless the window is unredirected

so the only thing i can imagine is that glXGetVideoSyncSGI is not available or broken on your driver (afair compiz has/had an option for a timer based syncing and as most ppl. run 60Hz TFTs these days, it's perhaps just the default.

grepping the kwin code resulted in (compositingprefs.cpp:300):
kDebug( 1212 ) << "intel driver, disabling vsync, enabling direct";
so it seems that intel does (did?) not support vsync'ing at all (excpt. of course a timer based variant where you need to enter the refresh rate) :-(

you don't happen to compile kwin yourself so you could add a debug notion when glXGetVideoSyncSGI is actually tested by the compositor, do you?

last:
setting a global vsync isn't trivial - there's no GL_VSYNC environment or so (well, for nvidia there is, but that doesn't count). so you'd have to figure the GPU and use a proprietary mechanism (like nvidia-settings or the xml stuff the driconf handles)

Great news! The latest intel drivers (2.8.1+) and linux kernel (2.6.31+) solve all video tearing with Kwin!

We can knock this bug off the list; I guess it was an upstream issue after all. Intel only supported a timer-based variant of vsync, which was causing the trouble. Now its support is complete and works like a charm.

Thanks for bearing with me through all of this. It certainly works perfectly in KDE4.3.2 as well, with the UXA graphics architecture.