On Mon, 16 Feb 2009 17:40:41 +0000 Thomas White <[email protected]> said:
> On Thu, 12 Feb 2009 18:08:56 +0530 > Andy Green <[email protected]> wrote: > > > If there was an effort to synthesize a VSYNC interrupt on Glamo (the > > real thing doesn't exist), is there actually anyone who would use it? > > > > Trying to figure out whether to close this as WONTFIX or have a go at > > it. > > I noticed the problems described in the ticket, e.g. tearing of the > green oscillating rectangle which appears during startup. Sharp > vertical edges moving horizontally are of course the worst possible for > showing up tearing. > > However, in that case, is it likely that it's more to do with the slow > video bus (combined with single-buffered, non-accelerated graphics) > than with the timings? Any estimates of how long the synchronisation > interval would be? If it's shorter than the time needed for a redraw, > then for single buffered graphics I can't see it making any > difference....(?) the rendering is actually double-buffered. the problem is yes - copies to video ram from the back-buffer (which in this case is an mit-shm buffer) will simply take much longer than a normal memcpy so its much more likely to catch it in the middle of writing during a refresh. > For the forthcoming 3D stuff, updates to the visible framebuffer will > be happening by a (fast) hardware blit (I don't pretend to understand > the more wider details of how/if X uses double buffering, but a blit > operation is normal for Mesa). If there are tearing problems then, 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. > then I think this an emulated vsync would be useful for us. However, I > think it'd be better to cross that bridge when we get to it. > > Has anyone noticed tearing with things that are definitely accelerated > using EXA? 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. imho - worry about vsync when you have performance and featureset in general "nice". -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
