Vsync on Glamo

Thomas White taw at bitwiz.org.uk
Tue Feb 17 12:42:45 CET 2009


On Tue, 17 Feb 2009 18:00:24 +1100
Carsten Haitzler (The Rasterman) <raster at rasterman.com> wrote:

> you can do this with a fast 2d blit currently - draw to pixmap and
> then xcopyarea - ecore_evas has this all there (enable avoid_damage).
> this adds latency to drawing though and will impact framerate. gl
> doesnt magically solve this. better than copying is to swap buffers -
> literally swap the frameubffer pointer. this is only sane and doable
> for fullscreen windows though. (we can argue about hacks to do it
> without with a reverse-copy - but i'll not go there). gl will also
> put you in the boat of limited resolution and not being able to do 3d
> in any buffer exceeding 511x511 - so you'll be dropping to 1vga just
> to sanely do it.

Of course I wasn't suggesting that GL is going to make any problems go
away :) - my comment was just a statement of how Mesa does things and
what I have in mind.

> vsync will be pretty useless for all but GL. technically the x sync
> extension can support vsync as a sync source for 2d. x could support
> it for double-buffer extension enabled windows. but pretty much any
> vsync comes with the caveat of ALSO having to redraw the whole screen
> for every update. that's good for 3d games - they modify the whole
> screen. it is close to useless for generic 2d unless done very
> carefully as 2d performance will suck so badly it won't be funny if
> you force whole screen redraws... unless you can get gl-es 1.1
> running at vga res... and still be sane.

What I had in mind (Mesa-wise) was to pause before blitting the 3D
buffer to the screen, delaying the blit until the vsync interval.  Is
there any reason something similar wouldn't work for EXA as well?

I can see how this would involve some kernel-level magic to take into
account that it takes time for a command sequence to get from one end
of the command queue to the other.  I can also see how it could mean a
maximum of one accelerated operation per vsync, which could be a
performance killer...?

> imho - worry about vsync when you have performance  and featureset in
> general "nice".

Agreed.  That was the main outcome of my slightly rambling email.

Tom



More information about the devel mailing list