I'm less interested in knowing whether someone broke something and more interested in knowing whether things are broken.
Currently, it seems that there should be no issue with the functionality of eventing. Any time evas_render_updates_internal() is called outside of the inside_post_render case, both events are emitted in the correct order. There is a change in when events can be emitted, as compared to the 1.7 branch which is my go-to for determining longstanding behavior breaks. At that time, the !changed case would return immediately, but it seems that this was changed during the 1.20 release cycle to instead skip to post render and handle any existing updates; this is easily triggerable by opening one of the elm_test glview windows under x11. It seems like there can never be any updates in existence when running this path, however, but the patch which introduced the change here seems to imply that it happens when the function is called recursively in async mode, meaning that potentially this is not as easy to notice. On Thu, Jul 5, 2018 at 11:18 PM Christopher Michael <cp.mich...@samsung.com> wrote: > On 07/05/2018 09:42 PM, Hermet Park wrote: > > Then someone broke post event as well. it shouldn't be happend without > pre. > > > > Agreed !! > > dg > > > > On Thu, Jul 5, 2018 at 12:15 AM, Mike Blumenkrantz < > > michael.blumenkra...@gmail.com> wrote: > > > >> This patch was necessary to ensure that RENDER_PRE and RENDER_POST are > >> always emitted as a pair. There are a number of internal > functionalities as > >> well as apps which always expect a PRE before a POST. Prior to this > patch, > >> it was possible to receive only a POST callback, which was very > confusing > >> to handle. > >> > >> On Wed, Jul 4, 2018 at 2:22 AM Hermet Park <hermetp...@gmail.com> > wrote: > >> > >>> commit ef471e4ecae793d9ac55949f627c8e25634ee242 > >>> Author: Mike Blumenkrantz <zm...@osg.samsung.com> > >>> Date: Fri May 12 12:08:32 2017 -0400 > >>> > >>> evas: ensure even no-op renders emit RENDER_PRE > >>> > >>> ref 67fae7aa0fdc9d778e8db88fc49bc149576994d2 > >>> > >>> > >>> yo, zmike, > >>> While reviewing canvas code, found out a patch that doesn't make sense > to > >>> me. > >>> Even I can't track any info with 67fae7aa0fdc9d778e8db88fc49bc1 > >> 49576994d2. > >>> So asking u directly. > >>> > >>> No render but how it trigger render_pre event? > >>> Render pre means it's just before rendering. this broke concept even > >>> compatibility. > >>> I totally can't agree on this patch. > >>> > >>> Could you please explain for this? > >>> > >>> > >>> -- > >>> Regards, Hermet > >>> > > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
