Vsync on Glamo
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
> imho - worry about vsync when you have performance and featureset in
> general "nice".
Agreed. That was the main outcome of my slightly rambling email.
More information about the devel