After the 121 commits of Cedric, switching desktops makes applications behave weird, such as content disappearing (only background). Fullscreen apps seem totally transparent.
same = my mail to e-devel about this summarizes it, but i'll paste here for documentation purposes:
i've been dreading updating e1fl for the past few days. the dread proved founded. the short version:
the batch below is pretty horrible. it leaves enlightenment glitching with garbage windows after a desktop switch or a second or 2. it makes enlightenment's restarts significantly slower (like from 1 second on this machine to like 2-3) with more visual bi-products (screen with just wallpaper visible for 0.5-1sec). the batch is also essentially unbisectable.
this batch leaves efl in a far worse state than before.
the batch itself is horrible because of the unbisectability. i have tried now about 15 commits (i lost count as i ended up in text console unable to write notes where i was writing them) and out of them only 1 compiled and ran at all without major issues. the largest amount of these just left e crashing on startup along with another group having edje_cc crash during compilation. while the crashes were gone by the end of the batch the above issues (short version above) remain.
finding out the causes of these issues is nigh impossible. i've already spent over 4hrs on the above trying to find them.
so... i've gone back to 0090384ef5ac9f9e939874a1bbf233298c9db930 which is good/works. i'm sitting on this (and i suggest anyone else do the same for now).
i'm going to wait until my wednesday morning here in seoul. if the above issues are not fixed by then i have no choice but to revert every patch from 36f8a70041a8a16249a07d5b7131d57a8a6ea95b to 75bb7c049f05176aef635bddcfb320c306b196bf from cedric because tbh - this is the problem batch as described. it's not personal. it's the reality of the situation. i have to do this because there is no way an efl release can go out with these in place in their current condition. this is 115 commits btw... so going over every single one to figure out what may or may not be involved is going to be a major time sink that i don't think can be done well other than maybe trim the start of this series and keep some of those. i might do so in the meantime.
so.. still a problem... what on earth would cause thi to barf in gl+native suerface though and not normally? ... if it was the same regardless of engine then something object related might be it...
as the description above. windows become garbage. it happens when objects are deleted it seems (so a desk switch involves creation and deletion of the pager popup for example). just open or close any windows and it happens. it just happens on its own within a second or so anyway.
junk. i'm GUESSING that it has to do with object deletion btw... it gets fixed if you resize a window until it then comes back again. so - description above., windows become garbage after a desk switch and various other things (desk switch is reliable in making it so). i reliably see this on 4 systems (1 nvidia, 3 intel gfx), so single and multi screen. it seems to work at least in 1 case i tested when i switched to software rendering in e... and that is what baffles me...
Okay, I had a few minutes to look into this. Running valgrind led to an issue which was enough to determine that the native surface was being destroyed immediately when one of its users was destroyed; this seemed to have been longstanding code which worked coincidentally until now.
I'm disappointed with the quality of discussion in this ticket. It seems like there was significantly more time spent trying to apportion blame than trying to diagnose or fix the issue at hand. Writing a simple test case (e.g., https://phab.enlightenment.org/P219, a very slightly modified version of example code for evas gl) to post on the ticket would have yielded much quicker results and been more friendly and helpful instead of constantly bashing the patch author--who didn't even create this issue.
@zmike - can you quote the amount of text in this ticket apportioning blame to someone? it might be a good exercise as actually there is none. if you read carefully "every patch from 36f8a70041a8a16249a07d5b7131d57a8a6ea95b to 75bb7c049f05176aef635bddcfb320c306b196bf from cedric because tbh - this is the problem batch as described." - it's a DESCRIPTOR like "the car i bought from ford". it might perhaps be construed to be blame but it wasn't and i tried hard to make it clear that its a descriptor with the "tbh" bit. but even if it was construed to be such how is that in any way more time apportioning blame than trying to fix it?
so ... prove your point because it's pure fabrication at this point that is offensive at least to me to just make this up. it's certainly not an impression any sane person could glean from this.
Sure, see below.
This is a tone-setting statement, which is why you've put it as the first part of the comment (and mail that it was copied from). By saying that you have been "dreading" updating to his patchset, it implies that you viewed Cedric's work as something to be feared (https://www.merriam-webster.com/dictionary/dread), which implies that you view it as potentially dangerous. The only reason a patchset would be "dangerous" in the context of software engineering is if it breaks something. Regardless of the eventual result of your update, by opening with this statement you've already established that you viewed Cedric's work as something likely to cause breakages. Given that you didn't perform any pre-review or testing on the series prior to its merge (as evidenced by your statement that you've been dreading the update, which can only be the case if you are still uncertain of the result), this means that you are not basing it on anything substantiated by technical background, and are basing it solely on its author's ability and the size/quantity of changes.
In essence, you viewed Cedric as unable to competently execute this patchset without problems. Regardless of whether that turned out to be true, you've expressed that sentiment here with this simple statement.
the batch below is pretty horrible.
Combined with your previous implication, this is a direct confirmation that you view Cedric's work as "horrible". Your later claim that "it's not personal" becomes irrelevant, as you've already expressed that it is, in fact, personal.
This is not only my interpretation of what you wrote, it's also the interpretation of people who have no context or interest in the project or its issues. Whether or not we are sane is similarly irrelevant; the reality is that this is how people who are not you can interpret what you have written.