Proper vsync and reduction of tearing
 

Hey everyone,

I've been spending the last few days trying to reduce tearing on pannable widgets (ie. photo browser) and the desktop.

I'm just starting this thread as a placeholder; as I make progress I'll post updates here. And, of course, if anyone has any insight I'd appreciate it. I'm a C coder and have fairly extensive experience with Qt, but virtually none with gtk, gles, hildon, clutter, etc. If any experts on this stuff are reading this you'll no doubt cringe at my haphazard and uneducated approach to this. :)

So far I've identified an ioctl() that seems to wait for vsync.

I assumed it didn't exist, but after applying a kernel patch to implement FBIO_WAITFORVSYNC I found by Brian Swetland against drivers/video/omap, I realized that the n900 doesn't seem to use that driver at all. It seems to use the one under omap2.

In looking through omap2/omapfb/omapfb-ioctl.c I discovered OMAPFB_WAITFORVSYNC, which seems to work!

According to my quick test, it cycles ~60 times/second, which I would assume is the default frame rate while the device is active. Interestingly, when the screen is off, that rate drops dramatically (I assume for power saving).

Now, I inserted this ioctl() into hildon-pannable-area.c (hildon_pannable_area_timeout) just prior to gdk_window_process_updates (), just to see what would happen.

Unfortunately it didn't seem to have the desired effect. Now I don't know enough about what happens, so my guesses would be:

1. gdk_window_process_updates () doesn't actually block and swap frames; frame swapping is asynchronous
2. updates are so slow the frame swapping occurs between frames anyway
3. it's not double buffered, and updates take longer than one frame

Again, apologies if the answer is obvious and I'm off the mark.. I'm still learning.

In any case, it appears the hildon desktop uses clutter and its own method for panning (ie. not hildon-pannable-area), and it was the main thing I was trying to fix, I so put hildon-pannable-area on hold, and focused on clutter.

I assume clutter is using the eglx backend on the n900?

All I've done so far is implement OMAPFB_WAITFORVSYNC and some debug code in clutter_backend_egl_redraw(), but it doesn't seem to get called on the device. Still trying to figure this one out.

I know enabling WSEGL_UseHWSync is supposed to have some sort of effect but I don't really see it (still tears badly), and I can't find any references to that variable anywhere in hildon-desktop, except in the bundled hildon-desktop.ini.

Another alternative I wanted to explore was reducing the LCD's refresh rate to 30hz, as this would reduce tearing even without frame sync. And there's no reason to have it any higher that I can think of. I assume it's just a matter of adjusting the pixel clock/timings.

Anyway, if anyone has any insights or words of wisdom to share (like I'm going in completely the wrong direction), please do share. :)

Re: Proper vsync and reduction of tearing
 

Think of the Angry Birds. :p And maybe mplayer too...

If there was a way to make the LCD refresh a control-panel / gconf-selectable value, it would make testing various apps easier.

I can't speak for specific HW side effects or whether it's a good idea more generally, but I'm curious where the 30Hz rabbit-hole goes. Let us know ;)

Re: Proper vsync and reduction of tearing
 

Not sure if you tried this or not, but I found that enabling "WSEGL_UseHWSync" in "/etc/powervr.d/hildon-desktop.ini" reduces tearing in transitions, though doesn't have much effect elsewhere.
I've heard that setting this value can make some systems unstable(which is why it's disabled by default), but I've had no issues, even at 1ghz.

Re: Proper vsync and reduction of tearing
 

Fixed in Harmattan :)

Re: Proper vsync and reduction of tearing
 

But, erm... Some of us -like- Maemo. Meego's not debian-based, so it's at -least- one step below maemo.

Re: Proper vsync and reduction of tearing
 

The packaging aspect is irrelevant to a great degree, since most people have an issue with the front-end rather than the back-end.

MeeGo will probably have actual vsync well before Maemo ever does, and rather than trying to migrate all of that stuff over to a hack on top of a hack that would be a Maemo rebuild (that you couldn't redistribute anyway,) you'd be better off just using Cordia on MeeGo DE and moving on.

In good time, of course.

Re: Proper vsync and reduction of tearing
 

I suppose some people don't. But as a developer, I can like whatever I want, for any reasons I want. And I like Debian.

The OP here is attempting to solve a problem in a -currently- available piece of software that's been released to the public. You guys are saying(essentially) "Don't bother fixing it, the next version will have it". Only problem is, MeeGo won't be officially released to the users on the N900 - sure, it'll be possible for devs etc. to install it, but without much official support.

I'd personally prefer -maemo-, which already -works- nicely, than MeeGo, which -might- get to the same point... Provided nokia doesn't drop it before it's done - Not too much of a stretch considering what's happened in the past.

Re: Proper vsync and reduction of tearing
 

Since you're trying...

Read:
http://lists.maemo.org/pipermail/mae...er/023281.html

Also, what you're proposing has been tried already:
http://maemo.gitorious.org/fremantle...9be0bac825e8c4

I at least pretty much agree with Eero here: vsync is a global problem that affects many applications, and cannot really be eliminated by editing just one of the pieces in the graphics stack: it has to be a coordinated effort.

In fact, you can easily see that there's still some tearing, albeit reduced, when removing hildon-desktop from the equation by either killing it or pressing Ctrl+Shift+N. While in this mode, you're neither using the SGX drivers, nor hildon-desktop, nor clutter, and yet there's still tearing that comes from Gtk+ and Xorg themselves.


Of course it is easier to fix in Meego, because Nokia now basically controls the toolkit.

Re: Proper vsync and reduction of tearing
 

Hey HellFlyer,

Do you happen to know exactly where the problem was? In another thread someone mentioned backporting something kernel related, but as far as I can tell the kernel does offer a blocking vsync call.

Or do you mean the Meego UI just supports it, and hildon-desktop/clutter don't?

Re: Proper vsync and reduction of tearing
 

Whoa.. that is freaky. :) Except that inexplicably that patch isn't using a global static and single open() on init... that's almost identical to what I've done.

I know I'm up against quite a challenge here but honestly if I can sync just the desktop panning... I'd be quite happy. It's the main one I find annoying and I bet it's possible.