Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: e comp object - stop being cricical where pixmap and win size dont match

[Carsten H. (T. R. <ra...@ra...>]

On Thu, 22 Jun 2017 19:43:52 +0000 Mike Blumenkrantz
<mic...@gm...> said:

> We provide stable releases for people who want a stable runtime experience.

git master should also be as stable as possible. i have gone to a lot of effort
to make it so over many years. the stability has suffered in recent
years. it's gotten better more recently.

but git master should be stable and not actively try and crash. not efl. not e.

> Running from a git build is for people who want to help with the
> development process by reporting bugs and testing new features. This seems
> straightforward to me, and I'm not sure how or why there could be any
> confusion between these types of builds. Based on your commit and your
> reply, it seems to me like you should be using a stable release since you
> are not currently interested in reporting bugs, only in making sure they do
> not impact your runtime experience.

i' m not going to use a stable build. over my dead body. git master should be
stable (or as stable as possible).

> As for eina_log, this does not provide anywhere near the same level of
> information as gdb output and will not be of any use in fixing such a bug.

this bug doesnt get fixed with gdb bt's either. CRI is useless in this case. i
looked at the bt. it isn't of use. thus using a CRI for it is just blowing it
out of all proportion .

> Your suggestion of creating infrastructure to do logging and upload the
> info is interesting, but in the end this is server-dependent and at this
> time I have no interest in adding more requirements on servers that I've
> been unable to access all day. At worst, the current system is familiar
> enough that IRC users (who are likely the majority of git users) can ping
> me with a paste of the crashdump.
> 
> Overall, your mail takes the position that a git build should always be
> production-ready. If that's the case, why do we bother with stable releases
> at all? Obviously this is an exaggeration, but I think it's more worthwhile

it is an exaggeration. git master shouldn't go to effort to be painful to
users. it is doing just that now. bugs happen. features ar enew and not
finished yet in master. but actively crashing when the crash provides no info
really on fixing it and it's possible to be frequent enough to make it a
usability issue... is bad.

> to target bugs as aggressively as possible in development builds so that
> the releases can have fewer issues. Aborting on critical errors on
> development builds is intended to be annoying because the alternative is
> that bug reports are not filed. Your mail is a perfect example of this, as
> you continue to justify your response by raising more issues which have
> never been reported on the bug tracker. The only reason that I am aware of
> the render size mismatch at all is because of your initial commit, which
> you made as a direct result of being annoyed by the abort.

you obviously were aware of the mismatch happening as there is code to check
it... otherwise why is it there? but it's not like the bt or that code provides
info on what caused it or how it might be fixed. i read it.  thats why i went
"this is not a critical thing at all... and it's not like this is going to
help solve it".

> On Wed, Jun 21, 2017 at 8:21 PM Carsten Haitzler <ra...@ra...>
> wrote:
> 
> > On Wed, 21 Jun 2017 19:40:05 +0000 Mike Blumenkrantz
> > <mic...@gm...> said:
> >
> > > Hi,
> > >
> > > I'd be interested in how you managed to hit this critical error since it
> > > should be impossible: there are a large number of checks across multiple
> > > layers which validate any resize attempt and restrict the geometry based
> > on
> > > current renderable size. The basis of a critical error in Enlightenment
> > is
> > > any issue which would be classified as "High" or "Showstopper" when a
> > > ticket is filed, and any render-related issues are immediately classified
> > > as "Showstopper". The reason why development builds of Enlightenment
> > abort
> > > on critical errors is to ensure that the backtrace remains available when
> > > this issue is reached and to more aggressively encourage the filing of
> > > tickets.
> >
> > resizing the enventor window. resized a few steps (like 0.2 sec with of
> > drags)
> > and book. e aborts. restart - resize it again for a bit... 2 sec later ..
> > bam e
> > aborts. ... rinse and repeat. again and again. thus why i consider this
> > highly
> > unsocial to go aborting on something so simple. i was totally unable to
> > resize
> > enventor to a sensible size because of this.
> >
> > you don't SEE the error... it's some transient along-the way thing.
> >
> > x11. nvidia drivers. sandybridge i7-2600. nvidia 970gtx. need probably
> > another
> > 20 or 30 windows around at the time so things get a bit more sluggish. the
> > slower the machine the easier it is to trigger (triggable on gtx970,
> > i7-4790
> > but takes much more time).
> >
> > as for bt's ... eina_log happily provides them for all errors... :) it at
> > least
> > doesn't  hang my entire desktop with a white box of death.
> >
> > > By changing this to a regular error, it is no longer possible for me to
> > > gather crucial information about the issue from users of development
> > > builds, and the underlying bug that you have triggered will remain
> > unsolved
> > > and propagate to release builds. This is a codepath which is reached on
> > > every resize operation for every window on both X11 and Wayland, so in
> > the
> > > case that the error occurs under any other circumstance (although I have
> > > never triggered it in the ~4 years that I have been running this exact
> > > piece of code), it will be extremely difficult for me to resolve any
> > issue
> > > which I am not able to trigger myself.
> >
> > repeated above.
> >
> > > Based on the above, I would suggest the following course of action to
> > help
> > > me resolve the issue:
> > > 1) Revert this commit
> > > 2) File a ticket using the crashdump which this error provides
> >
> > and live with e crashing every time i resize a window? how many other
> > people
> > get this and just go aaargh! e is unstable!". here is how i see issues like
> > this:
> >
> > if it's an issue that directly impacts usability doing something common
> > (this
> > does and happens again and again doing the above) there will be people
> > affected
> > and fixing it to not happen is a major priority to get into git ASAP.
> > tickets
> > or not. when i looked ... it just didn't warrant this level of "just crash
> > -
> > users love that". it's not critical at all. it's an effectively invisible
> > visual glitch (you explicitly just checked pixmap and window size match).
> > visually i never can see it. it fixes itself up before the resize is done.
> > it
> > does not WARRANT a critical. why the pixmap doesnt match the window size is
> > probably a really intricate syncronisation issue somewhere that is going to
> > take a llooooooooong time to hunt and in this case just "doesn't matter".
> > it
> > could even be driver-side (as things get more sluggish on the server side
> > and
> > buffer allocations for resized pixmaps may take a lot longer etc.).
> >
> > FYI despite this check here i SOMETIMES fine one of my terminology windows
> > being "blurry" (pixmap != window size) at the END of a resize with
> > everything
> > stopped/stable... and this CRI doesn't catch it... :) it's very rare and i
> > have
> > no reliable way to reproduce it.
> >
> > here's a suggestion:
> >
> > actually gather the bt's with no interruption like eina_log does... (maybe
> > add
> > an eina api to do this?) then process them into something readable with
> > eina_btlog and have e at some time later offer to upload these (like
> > shot.php
> > screenshots work) as a report? you'd get a hell of a lot more reports on
> > issues AND users would not complain because you automated the reporting
> > process
> > to "hit ok". don't pop up a dialog every time it happens... just log it.
> > flag... and maybe 15 mins later when idle, report "i have 4 issues logged.
> > can
> > i report them? here they are ok/cancel"...
> >
> > > If the issue is preventing you from using your system or you lack the
> > time
> > > to file a ticket, there are still options available which do not impact
> > my
> > > ability to solve issues of this type:
> >
> > pretty showstopper when i can't resize a window... i think you've raised an
> > issue far beyond it's importance. the point of e is to be stable day to
> > day.
> > this particular test here i just can't see warrants forcing a crash.
> >
> > > * Locally disable the error
> > > * Use a stable release
> >
> > in this case the bt isn't going to help you other than "pixmap and window
> > don't
> > match". you won't know why... why may even have nothing to do with our
> > code at
> > all... :) my view is that this doesn't warrant crashing all of e to get a
> > bt
> > that isn't helping.
> >
> > > On Tue, Jun 20, 2017 at 10:32 PM Carsten Haitzler <ra...@ra...>
> > > wrote:
> > >
> > > > raster pushed a commit to branch master.
> > > >
> > > >
> > > >
> > http://git.enlightenment.org/core/enlightenment.git/commit/?id=e288852393d27cadd58f0862758d21bbe6cf24ab
> > > >
> > > > commit e288852393d27cadd58f0862758d21bbe6cf24ab
> > > > Author: Carsten Haitzler (Rasterman) <ra...@ra...>
> > > > Date:   Wed Jun 21 11:31:24 2017 +0900
> > > >
> > > >     e comp object - stop being cricical where pixmap and win size dont
> > > > match
> > > >
> > > >     now i resize some windows and am in a white box of death each
> > time...
> > > >     this is really unfriendly... so downgrade to an err ad this is a
> > > >     recoverable error.
> > > > ---
> > > >  src/bin/e_comp_object.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/src/bin/e_comp_object.c b/src/bin/e_comp_object.c
> > > > index c02069b28..c81fad531 100644
> > > > --- a/src/bin/e_comp_object.c
> > > > +++ b/src/bin/e_comp_object.c
> > > > @@ -2550,7 +2550,7 @@ _e_comp_smart_resize(Evas_Object *obj, int w,
> > int h)
> > > >                    //evas_object_size_hint_min_set(cw->obj, pw, ph);
> > > >                 //}
> > > >               if ((ww != pw) || (hh != ph))
> > > > -               CRI("CW RSZ: %dx%d || PX: %dx%d", ww, hh, pw, ph);
> > > > +               ERR("CW RSZ: %dx%d || PX: %dx%d", ww, hh, pw, ph);
> > > >            }
> > > >          evas_object_resize(cw->effect_obj, w, h);
> > > >          if (cw->zoomobj) e_zoomap_child_resize(cw->zoomobj, pw, ph);
> > > >
> > > > --
> > > >
> > > >
> > > >
> > >
> > ------------------------------------------------------------------------------
> > > 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
> > > enl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    ra...@ra...
> >
> >


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...