Page MenuHomePhabricator

Applications content disappears when switching desktops on E
Closed, ResolvedPublic

Description

After the 121 commits of Cedric, switching desktops makes applications behave weird, such as content disappearing (only background). Fullscreen apps seem totally transparent.

JackDanielZ triaged this task as Showstopper Issues priority.

I forgot to mention that I am on Arch Linux updated, EFL and E updated. I use X11 (sorry guys:-))

raster added a subscriber: raster.May 27 2018, 5:02 AM

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.

can you ytry switching to software rendering in e's compositor settings to confirm the bug goes away? i think i found that made it work again on 1 machine i tried it on.

JackDanielZ closed this task as Resolved.May 29 2018, 11:04 PM

I am always in software rendering cause I don't need more than that. And yes, the bug have totally disappeared since Marcel's patches :-)

Thanks guys for all

raster reopened this task as Open.May 30 2018, 3:29 AM

ok then - try gl in e's compositor - broken for you still? because it is here...

I just tried - it is still broken in OpenGL.

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...

zmike added a comment.May 30 2018, 4:50 AM

What exactly is the issue when running in GL?

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.

https://www.enlightenment.org/ss/display.php?image=e-5b0e303f8d8576.82049191.jpg

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...

zmike added a comment.May 30 2018, 2:47 PM

Didn't have enough keyboard time to check on this today, will try tomorrow or Friday.

zmike added a comment.May 31 2018, 4:18 AM

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.

Sorry that this ticket disappointed you! I am sure you can find other tickets more interesting!

Anyway, thank you for the patch I will test it soon.

@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.

zmike added a comment.May 31 2018, 6:41 AM

@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.

i've been dreading updating e1fl for the past few days.

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.

zmike added a comment.May 31 2018, 6:42 AM

Anyway, thank you for the patch I will test it soon.

Unless you're using Wayland, this patch will not have any effect for you. This is a tricky issue to solve, so it may yet be some time before it can be fully fixed.