On Sun, 8 Dec 2013 09:09:50 -0500 Michael Blumenkrantz <[email protected]> said:
> On Sat, 07 Dec 2013 21:48:11 -0800 > Carsten Haitzler <[email protected]> wrote: > > > raster pushed a commit to branch master. > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=65a1ed752ed08de58d2eea550ad1bbc2d451e8d9 > > > > commit 65a1ed752ed08de58d2eea550ad1bbc2d451e8d9 > > Author: Carsten Haitzler (Rasterman) <[email protected]> > > Date: Sun Dec 8 14:44:26 2013 +0900 > > > > comp - disable grab by default due to it causing erratic rendering > > > > so i found something interesting. the grab option causes some erratic > > that IS interesting. how did you find this? while trying to add the framerate sync feature i just puhsed into ecore-evas. i was sure i had my code right, but sometimes it just wouldnt wake up at the right time. i did a LOT of printf debugging with detailed time stamps/framecounts and more and eventually found that the jumping i was was every second frame being off by like 80% of a frame - thus basically missing a slot. literally an ecore loop wakup was not happening... i dbeuggined it down to evas rendering taking an erratic amount of time.. sometimes it took 0.1 frames worth of time or 0.05 or so.. other times 0.8... and like swapping back and forth every frame. i know that on my desktop here it should easily manage to render the tiny amount in no time flat... so the lower number looked right... so i was wondering what could cause rendering to jump about like that... surely not internal rendering code itself... so my guess was an external influence... i remembered the grab server option.. i turned it off.. and VOILA! smooth as a babies bottom. my code was right -it was being held up by x. when you grab the server all other clients are ignored until the grab is released. so my suspicion was one of the round-trips within the xshmputimage (the xsync one - as there is only one) was being blocked by this. > > framerate in clients IF thoise clients have to sync to the xserver and > > themselves try and render more smoothly. it masically means animators > > get delayed due to unusually long render times because of this. this > > fixes that. this also adds a comp config version number allowing the > > code to upgrade a users config to turn this off and thus allows for > > future upgrades too. > > --- > > src/bin/e_comp.c | 17 +++++++++++++++++ > > src/bin/e_comp_cfdata.c | 4 +++- > > src/bin/e_comp_cfdata.h | 3 +++ > > 3 files changed, 23 insertions(+), 1 deletion(-) > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
