Created attachment 107505 [details]
Here you can see a video of it and also more important information is in the youtube description: https://www.youtube.com/watch?v=X_c-26mB304
Like the text says, there seems to be some kind of 2D drawing action in Xorg that takes maybe a thousand times longer with nouveau than usual. But this drawing is rarely used, i.e. mostly only on window creation, so the delay doesn't get as apparent in most cases you run into (I suppose with my limited knowledge that this drawing actions are single Xlib graphic contexts like you can create with XCreateGC, created and rendered for the first time or changes in their palette or something).
So this makes applications open in a sluggish manner and with certain programs, like in the video example, it causes insane delays (like 10ms becomes 3 minutes) that extremely impair working properly with them.
I only really ran into this on my work PC, which has slower+older GT8400 cards, but at home once I tested it with GT430 also and I would rather say that the same sluggishnes was present, but maybe due to different causes?
00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 8400 GS Rev. 3] (rev a2)
03:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8400 GS] (rev a1)
Linux WORKPAQ 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux
X.Org X Server 1.16.1
You must be hitting some case that we don't handle with EXA (or worse yet, some case that EXA in general doesn't handle well, but that's less likely).
One quick thing to try is to use GLAMOR -- with xf86-video-nouveau 1.0.11 you can set the AccelMode driver option to "glamor". [Note that I've seen a bunch of X crashes when glamor is enabled, and it apparently locks you out of creating core GL contexts somehow, so it's not a panacea.]
I can't tell your technical level, but if you're up for it, grab the xf86-video-nouveau source, and in nouveau_local.h switch the #if 0 to #if 1 above NOUVEAU_FALLBACK. That will print a ton of stuff in your Xorg log about which actions are falling back. Hopefully it will be easy to identify which ones are hitting the rdesktop silliness.
Also... you appear to have an uncommon X setup. You're using ZaphodHeads, but you're not using xinerama. Does that mean that everything is on separate X screens? But I also see one of the cards being added as a "GPU" card. It's all a little odd... Are you using reverse prime at all? That's probably also not the fastest thing in the world.
By the way, I assume this all works fine when running rdesktop off the intel-connected screen?