No announcement yet.

Wayland/Weston 0.95 Land In Ubuntu 12.10

  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Ansla View Post
    That's pretty much what Gentoo is trying to do, and it's doing a pretty decent job. I have 3 machines running Gentoo, 2 of them running over plain alsa and one with PA, all 3 work flawlessly. And I could even switch one to OSS if I wanted, though I think there would be some apps that no longer have OSS output even as compile time option...
    If you compile, you can chose whatever you like in every distribution obviously, at least if the upstream developer support it as a compile directive.


    • #32
      Originally posted by Akka View Post
      If you compile, you can chose whatever you like in every distribution obviously, at least if the upstream developer support it as a compile directive.
      If he knew how to do that, he obviously wouldn't be ranting here.


      • #33
        Originally posted by Ansla View Post
        Can you elaborate a bit on this? From what I know vsync should work the following way: once frame x is sent to the monitor rendering starts for frame x + 1 with whatever information is available at that time and not render anything else until the next vsync event. Now, at 60 fps the interval between frames is ~16ms. If rendering the next frame took just 4ms and somewhere between ms 4 and 12 new info comes from another player should a properly coded engine render a new frame that takes into account this new info?
        you're right about how rendering with vsync enabled works, but there's no right way for every game, although there are definitely wrong ways to go about stuff like this. actually, for arcade style / old school games with fixed timesteps, as well as most game system emulators, double buffering and syncing to vblank on buffer swaps is optimal on modern hardware when it comes to minimizing input latency and getting a consistent framerate while eliminating tearing.

        a game like this may have a main loop that looks something like this:
        while(not done)
        the above code under ideal conditions (proper gpu drivers, no lag from a non-crt display, etc) works like so:
        while frame_n calls the first 3 functions, frame_{n-1} is being rendered on the gpu, and frame_{n-2} is being scanned out on the display. frame_n then sends a swapbuffers command which should put it to sleep until the vblank fires. so with a game like this, when you press a button you should see a completed frame on the screen showing the games reaction within 3-4 frames worth of time later (for 60hz: 3.X/60 secs), depending on when you pressed the button - ie best case right before readInput, worst right after. (just in case you're wondering why it's 3-4 frames later and not 2-3, it's because a given frame only starts the scanout 2 frames worth of time later, it takes 1 additional frame for it to be completely displayed)

        also emulators can benefit from 120hz rendering, both to reduce lag and for simulating the effects of a crt on a non-crt displays.

        i also want to add that i'm worried about how wayland/weston will handle games/emulators that rely on vsync for timing, like the above example does. i mean, fullscreen applications shouldn't be a problem as it should just unredirect them, but i've yet to see a compositor that's able to work well when running these kinds of applications in a window (compiz and windows aero cannot, can't speak for macosx..)