Personal i dont like it if there are two much options for the user... if we really need special options for each game we should move it to a config file or "enhance" the patch-ini-file of each game instead of overloading the menu. 99 percent of the users will not understand the options at all.

Of cause this is just my opionen but the defaults should be the options that work all the time (DC off, quantinzer off, idle skip off,...) and enhancment can be activated on game base. If a game doesn't have an option file it will be slow but it works.

cheers

ps: this is my just my opionen there is no need to revert something :D

We should totally add a Settings Window. This will be put under Advanced and on by default. Interpreter/JIT combo-box should also be added.

Issue submitted.

WTF I get 550 MHz idle skipped and sometimes very slow emulation. Pending a fix :)

yeah, what XK said above me. A main dolphin settings dialog would be sorta nice, but many times such things just end up spamming the user with options which have varying degrees of effectiveness.

I can already see the 700 menu items in the emulation menu :P

Well, F|RES, I agree 100% about "i dont like it if there are two much options for the user" but for real releases only.
At first I just wanted to #ifdef it. I change my mind because some of us (including me) may want to investigate quickly some dolphin's behavior with or without an option.
As dolphin is in wip, I assumed we could add some dev tools without taking care about user right now. 

XK: Yes, better, a SettingxWd could be "hide" behind a cl like the "/d". 

Anyway for you F|RES :p , I can #ifdef it for DEBUG/DEBUFAST. Let me know.

can't it just automatically decide what setting to use according to how much FPS you get?

Tried to add some checks (it's not really FPS but rather MHz rate that is emulated) but they didn't work.

'Idle-skipping' is great in the way its moving the bottleneck from the general load/store instructions to the graphics emulation, allowing for very fast emulation in, for instance, 2D environments or less complex ones.

In any case, though, I think that some sleeping is required anywhere in the code and (maybe) coordinated with the current MHz so that Dolphin won't starve the other processes. But then again, speed has its price :P

Are there any other optimizations for idle PowerPC/Gecko operations?
http://pds.twi.tudelft.nl/vakken/in1200/labcourse/instruction-set/

XK: I'm lost for now... I don't get why gemu is slower with complex 3D if it became the bottleneck.
Not a clue, but in SC mode I have observed lots of CatchUpGPU when that ZWW f***** island appear.
and here is the profiling result of about the 30 first second in WW (SC+OGL):
TIC_TIMING_ADVANCE___	 -> 20.340691  <- call the CatchUpGPU 
TIC_CATCHUPGPU_______	 -> 13.402974  <- BAD! fifo? IPC timings?
TIC_JIT______________	 -> 0.369846 
TIC_RUN______________	 -> 30.663580  <- run time
... could be a lead.

And btw, I don't like thread sleeping everywhere, I prefer lock/unlock for now. Later when all our CPUs will be burned we could put some slow down features :p

PS: I'm new here so I hardly get the all thing. Feel free to slap me if I didn't get well coding politics or technical stuff... No problem... (I'll remember it anyway :D )

Added a positive review. This helps a lot in places like intro videos and menus. Great addition. Ector said a while ago that it wasn't possible to combine idle skipping and dual core :)

jpeterson57: I didn't know it was impossible :p
But check r658 and let me know if it's better or not.

changing my vote on this one. Never disabled idle skipping in DC and was happy with it