On Mon, 14 Nov 2016 16:06:13 -0600 Derek Foreman <der...@osg.samsung.com> said:
> On 13/11/16 07:15 PM, Carsten Haitzler (The Rasterman) wrote: > > On Sun, 13 Nov 2016 13:53:04 +0900 Carsten Haitzler (The Rasterman) > > <ras...@rasterman.com> said: > > > > oh... i now see the same issues with redraw/animator/whatever on nouveau as > > i did on the rpi... so this is definitely broken-pants. :) > > Excellent timing. :) > > Until Friday, the animator_tick stuff used in the drm animator code was > broken - it didn't properly disable the timer based animator. Both time > ticks and pageflips were firing at the same time. > > This is the reason why we get an inconsistent buffer age, and end up > using more buffers than we should at times. > > Cedric dealt with that Thursday, but that exposed a bug in my drm tick > code that was preventing pageflip based ticks from firing properly. I > had it fixed locally, but didn't get a chance to sort the commits and push. > > It should work better now. it still has a miss-frame bug as below unless you redesigned it to queue flips from a thread > >> On Sun, 13 Nov 2016 12:31:49 +0900 Carsten Haitzler (The Rasterman) > >> <ras...@rasterman.com> said: > >> > >> FYI - i disabled _drm_animator_register, _drm_animator_unregister, > >> _drm_evas_changed from the ecore_evbas func struct for the drm engine and > >> lo and behold... mouse moves smoothly and reliably. yes. there are "gpu > >> goes slow" hiccups but the whole drm animator stuff is really bad - > >> especially on an rpi. : ( the elementary_test animation is now pretty > >> decent. its smooth > > It's not heavily tested and it has some bugs, but I think "really bad" > is a bit hyperbolic. :P not hyperbolic. it's impossible to use a mouse, or close to it. i get maybe 1 fps or 0.5fps. the mouse moves at this rate. as does everything... UNTIL another animator is continually on - eg like hovering over an ibar icon. then its ok. i wouldnt call this hyperbolic. > >> (well i disabled the manual render messing the wayland engine was doing as > >> per below). > > Good luck with that. You can get dropped client frames (as in: the most > recent frame gets dropped and you sit there looking at a stale frame) > and maybe a deadlocked compositor under certain corner cases. > > It would be probably be safer to wait for me to fix that than to > randomly badger it. > > It's known broken and has been on my todo list for ages, it just isn't > broken enough to make it top priority. it's still broken tho... just minorly (eg were someone else to use norender push/pop in elm - and elm can do this automatically eg when minimizing etc. so elm will mess with manual render as well as the ecore evas wl engine). > >> > >> this needs some serious testing across a wide range of hw (slow and fast) > >> and careful thought on mainloop blocking conditions and how this affects > >> everything etc. > > What's blocking the main loop?!? opengl rendering stuff. my time traces show a lot of the time its under 16ms but then it goes over to like 20ms then takes 50ms then 80ms or whatever for 4 frames then back down to 12-13ms ... if you are close to the 16ms boundary... you may miss a frame and thus drop from 60 ro 30hz as you just cannot queue a page flip in time. by design the current scheme for drm page flip has this very annoying bug. i discovered that in the vblank animator a long time ago and fixed it by dedicating a thread to the task so it cant be blocked. either way this is the main loop. it runs code totally out of control of efl. an app could sit and calculate pi to 100283892392300348 decimal places or calculate fractals or do blocking i/o that we cant control (even evas does blocking i/o on image header decodes) and these add up. if you happen to miss the timing for another page flip you have to WAIT for the next one and that means your framerate suffers badly. you now SLEEP not even trying to render another frame. you wait for the next page flip event which is maybe 14ms away (if the last frame took 18ms) and THEN begin that render. as long as your renders are nicely under 16ms (or whatever your frame gap is) then its fine, but once you get just near or over it things go bad with a scheme of inline scheduling. you have to schedule at least several frames in advance then Or use a scheme that can preempt and schedule anyway - eg a thread. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
