On Tue, 17 Feb 2009 18:00:24 +1100 Carsten Haitzler (The Rasterman) <[email protected]> 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 _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
