hmmmm. i'm reading this code and it seems broken. let's start with the simple one.
1) ecore_evas_wayland_common.c: this shouldnt MESS with manual render at all. at most it should just have if (wdata->reset_pending) return 0; added to the top "not going to do this" section in _ecore_evas_wl_common_render () and remove all the other manual render things. ecore evas already forces all rendring to be driven by an animator out of the box. this animator should either be totally driven by frame request events from wayland (compositor) itself OR at least hook it up to the drm device... but either way this code is wrong as it messes ith the manual render flag that is ALSO altered via api from ecore_evas "public api" calls which are called by elm win etc. so this has to go... it's wrong at a minimum and likely causing issues. 2) ecore_evas_animator_tick() has a region but NO TIMESTAMP. please look at ecore_x_vsync.c and specifically ecore_loop_time_set() that uses the vblank timestamp to get EXACT vblank timing into. this is a must for having a STEADY animator with STEADY timepoints. a region - fine... but you need a timestamp too. now to the nasty one... 3) ecore evas drm engine using pageflips for animation. errrr... WHA? no. well ok. tell me if i'm wrong. to be able to tick the animator the code DOES a page flip... THEN uses the page flip event to drive the animator? what? this is just wrong on so many levels. animators are not a RESULT of altering the fb from some previous page flip. they are a tick that says "the screen scanout is refreshing NOW and you should time your animations NOW to THIS point". i suspect this code is a huge source of brokenness. why are we scheduling a flip ... we don't even HAVE a new frame yet? i know i know... it's "simpler" and you can get a flip event per output... BUT firstly the timestamp is not even USED from the page flip event in the code i'm reading, secondly i have no idea WHAT timestamp this would be (i know the vblank events are the vblank interrupt timestamp). the pageflip COULD be some other time during scanout (end of vblank, end of scanout? something else?). but either way it's not used and should absolutely be. but ... in order to GET an event you have to do a flip... and i'm reading ecore_drm2_fb_flip() and that is seemingly what is being done to just get this event. it seems to be able to do a "null flip" (flip the current buffer to itself), but i'm not so sure this is reliable given the api and code - is output-next always null when we register an animator with _drm_animator_register() ? what happens when we do a null page flip THEN do a real one? also here comes the stinker. what happens when we MISS a whole frame because something went slow? we're scheduling from the mainloop. since we are asking for the NEXT animator tick from a page flip... we only schedule a new page flip once we already have figured something changed in the ecore_evas or the animator is registered etc... imagine for a second we have a 16ms frame gap (approx 60hz). what if we spend 18ms this frame rendering or doing something? we MISS the next opportunity to page flip, so we actually have to wait another 14ms for the next frame. thus we do either 60hz, or 30hz... but can never play catch up and squeeze in another frame because we missed the opportunity to schedule one. this scheme using page flips is broken "by design" in this way. please have a look at ecore_x_vsync.c. yes it's complex. it does whitelisting of working drivers and handles some broken drm info stuff. it dlopens libdrm to not have to link or compile against it at all. it also handles timeouts on drm vblank events and after enough will switch to time based animation. but ignore that... it uses a dedicated thread JUST for scheduling vblank events and reading them so it will never miss one. in the dedicated thread ALL it does is schedule a vblank and sleep waiting for it to happen (or a command from mainloop to stop doing events, timeout in case of screen going off to fake animation ticks while vblanks are mising or exit etc.). so it can never (on even a heavily loaded system and irrespective of what the mainloop does) miss a frame... unless it literally cannot manage to wakeup from the fd coming alive. call drmHandlEvent, write the timestamp down an fd, check cancellation flag, the come back to scheduling it again within 16ms. you'd have a fundamentally broken system if this was not possible as this thread does nothing else. there is a good reason it is done this way. i have found that we HAVE managed to lose frames and drop from 60 to 30hz and the effects are not pretty. the drm engine really has to do the same. and i'm not so sure you can use page flip events then as you have a completely independent thread trying to use the drm fd to get these events and you don't want IT flipping pages to the same or a new one... so you likely have to use a separate drm fd like ecore_x_vsync.c does and rely on vblank events which are passive. chances are this code should become common/shared. but what i am reading right now smells of broken... and on my rpi i see broken... in fact the mouse just doesn't ever (barely) render/move unless i hold it over an ibar icon that is pulsing and animating... then it works, but move my mouse away... it basically doesn't work. i suspect this pageflip "to myself" trick is to blame. yes the vblank code only keys off a single screen and will ignore all other vblank events. i guess this would have to be figured out somehow. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
