Accidentally wrote a comment related to this on bug on another bugzilla <https://bugs.freedesktop.org/show_bug.cgi?id=101383> so copying it here where it is more relevant:

It's currently not possible to affect the refresh rate of the actual drawing. This is not by design; it's simply not implemented. Making it work involves updating MetaRendererNative to pass around refresh rates and presentation timings to ClutterStageCogl, so that it can schedule frames given the actual refresh rate of the monitor. Currently, it'll just fall back on 60 Hz, which of course is not good.

Another related issue is that if one monitor is 144 Hz, while another is 60 Hz, we'd still end up drawing at 60 Hz, as mutter still doesn't support drawing separate monitor as individual frames.

In other words, making it work with multiple monitors with different refresh rates is non-trivial, but making it (non 60 Hz refresh rates) work for just a single monitor is probably not very hard.

I have 75hz monitors because I think 60hz is not enough in an interactive environment, simply do not feel smooth. For my eyes 75hz is a much more smooth experience than 60hz, 75hz is enough for me for the desktop but higher refresh rate would be great.
This is true on kde and matedesktop not true in Gnome-Shell. If I set 75hz refresh rate on the monitor by randr mutter continue run at 60hz and the experience is horrible, it's become a stutter fest.
This is why I just run plasma desktop (never used in 20year and it's great).
Not supporting refresh rate > 60hz in 2017 is a NO-GO, gnome-shell is not usable for me. This is a shame right now because the wayland support now is great.
I hope this will be addressed as soon as possible.

I am having the same issue. I have a 144 Hz monitor and cannot use it at its full potential under Wayland. While I am very happy with its current progress since switching to it in Fedora 24, it still has some ways to go.

> Currently, it'll just fall back on 60 Hz

Do you mean these lines in clutter-stage-cogl.c?

  refresh_rate = stage_cogl->refresh_rate;
  if (refresh_rate == 0.0)
    refresh_rate = 60.0;

(In reply to Jan Niklas Hasse (Account disabled) from comment #4)
> > Currently, it'll just fall back on 60 Hz
> 
> Do you mean these lines in clutter-stage-cogl.c?
> 
>   refresh_rate = stage_cogl->refresh_rate;
>   if (refresh_rate == 0.0)
>     refresh_rate = 60.0;

I'm not sure exactly things are hooked up these day, so I can't say what role this plays, but overall  the goal is not simply to get the application at the same frame rate as the display, but have it locked to the actual refresh - which is clearly not working if the display is refreshing  at 75hz and the app at 60hz. So it's necessary to figure out where that's broken or not implemented - which could be anywhere along the 

 glx => xwayland => Mutter => KMS

path.

(In reply to Owen Taylor from comment #5)
> (In reply to Jan Niklas Hasse (Account disabled) from comment #4)
> > > Currently, it'll just fall back on 60 Hz
> > 
> > Do you mean these lines in clutter-stage-cogl.c?
> > 
> >   refresh_rate = stage_cogl->refresh_rate;
> >   if (refresh_rate == 0.0)
> >     refresh_rate = 60.0;
> 
> I'm not sure exactly things are hooked up these day, so I can't say what
> role this plays, but overall  the goal is not simply to get the application
> at the same frame rate as the display, but have it locked to the actual
> refresh - which is clearly not working if the display is refreshing  at 75hz
> and the app at 60hz. So it's necessary to figure out where that's broken or
> not implemented - which could be anywhere along the 
> 
>  glx => xwayland => Mutter => KMS
> 
> path.

The situation in the native backend is that it's simply hard coded to 60. In the above code, stage_cogl->refresh_rate IIRC is always 0.0. There are two things we need to do: split up stage frame scheduling into per monitor, then use the refreh rate from the monitor when scheduling.

I would like to look at the code, is there any internals guide that introduce the to the rendering stack? I would like to see gnome run at 1000hz (why not).

Comments 4 and 6 are incorrect, but in the right function.

There are two root causes of this bug:

1. The Wayland backend is missing hardware presentation timestamps etc, which causes clutter_stage_cogl_schedule_update to return even earlier:

  if (stage_cogl->last_presentation_time == 0||
      stage_cogl->last_presentation_time < now - 150000)
    {
      stage_cogl->update_time = now;
      return;
    }

That is fixed in https://gitlab.gnome.org/GNOME/mutter/merge_requests/144

2. For Xorg (and soon Wayland) that has presentation timestamps and the correct refresh rate information, we accidentally ignore the correct refresh rate in master_clock_next_frame_delay because:

  swap_delay = master_clock_get_swap_wait_time (master_clock);
  if (swap_delay != 0)
    return swap_delay;

and when swap_delay is zero, we may end up using clutter_get_default_frame_rate (which is 60) to calculate the next update time.

So the remaining fix we need relates to master_clock_next_frame_delay, and eliminating the call to clutter_get_default_frame_rate() somehow. Without breaking it :)

Oops. I spent too long working on other branches no realizing I had already completed the fix for this bug. Here it is:

https://gitlab.gnome.org/GNOME/mutter/merge_requests/171

Hi Daniel,

I have rebuilt mutter from Ubuntu's latest .dsc package and  include your changes in the #171 merge request, and so far it seemed to have fixed the issue for me.

Both my monitors are at 144hz and the windows now seem to be running more smoothly.

Thanks

Thanks Jason.

If you can then please comment in https://gitlab.gnome.org/GNOME/mutter/merge_requests/171

Also, the code changed yesterday if you would like to retest.

Workaround:

1. Add a line to /etc/environment like:
     CLUTTER_DEFAULT_FPS=144
   or whatever your monitor's real refresh rate is.

2. Reboot.

Fix landed in mutter master:
1. https://gitlab.gnome.org/GNOME/mutter/commit/e9e4b2b7
2. https://gitlab.gnome.org/GNOME/mutter/commit/e8c27603

Closing as per comment 13.

Hi. how can i apply to fix the problem. I am on ubuntu 18.04.
Thank you.

btw, i did try the work around with no success.

Marius,

You are right that the fix is not yet in Ubuntu 18.04. However that should be discussed in the Ubuntu bug instead:

https://bugs.launchpad.net/bugs/1763892