The Return Of The Releasinator

In what has become a frustratingly long process compared to previous releases, 1.9 alpha (MYSTERY RELEASE 2K14!!!) is now out. I included a special Billy Mays for all my loyal readers here as well.

 

Advertisements

The Iceman Cometh

Just a quick update today, the EFL 1.9 release freeze has begun. The release is scheduled to happen in 2 weeks, so hopefully Stefan Schmidt returns from his glacier tours before then.

 

Our wiki¬†received some hacks last night which should allow reading without being logged in. A big thanks to Carsten “Widget Wrangler” Haitzler for that.

 

Most E19 commits recently have been related to fixing shadow display. Not very exciting. Stay tuned, however: there’s more announcements in the works!

Tiling In The Name Of

I don’t have anything worthwhile of my own to blog about, so I’ll keep the postcount increasing with a quote from the mailing list:

 

From: Tom Hacohen <tom.hacohen@samsung.com>
To: Enlightenment developer list <enlightenment-devel@lists.sourceforge.net>
Subject: Re: [E-devel] Enlightenment Tiling v2.0
Date: Tue, 04 Feb 2014 16:01:42 +0000

Hey guys,

I have a few updates regarding Tiling2:

Due to popular demand, the module is now external and in it’s own repo.
You can now easily compile it with your existing e19. It’s still e19
only, no e18 support.
Get it from:
https://git.enlightenment.org/devs/tasn/e19_tiling2.git/

A lot has been done since I’ve started it. There’s now a documentation
page on phab that lists what’s there, what’s not and how to use:
https://phab.enlightenment.org/w/emodules/tiling2/

Only thing that I still need to do before considering it “1.0” is
finding a way to easily promote/demote. I still haven’t found a proper
UX way of doing it. By that I mean, moving items up/down the tiling
tree. If you have an idea, please let me know.


Tom.

Anatomy Of A “Hard” Bug: A Brief, Yet Boring Interlude

I was finally able to reproduce an interesting/annoying issue today, and it turned out that I remembered my intent to blog about it from last time. Here’s the result.

The Problem:

Some windows would fail to render until they either resized or changed their visuals (damages).

Initial Thoughts:

It was difficult to pin down exactly what triggered this issue since I had only heard of it from others without actually experiencing the issue first hand. In general, rendering issues are impossible for me to fix unless I can get them under a gdb scope, so I wasn’t spending too much time trying to figure it out; in most cases, these types of issues are the ones that I fall face first into at some point. As expected, that point was today while working on yet another Yakuake-related issue (fuck you, shaped windows, even though it was unrelated to shapes).

When I did discover a way to reproduce this, I was a bit confused since it only happened in this one particular case (Yakuake menus in Xephyr after restarting E, and only after the menu had already been shown once). Something like a sacrifice to the rendering daemons to get the app to break, I guess? Anyway, I buckled in for a long debugging session which ended up not being very long at all.

Here’s a shot of my workspace upon encountering the problem:

Starting Point:

Immediately after examining my rendering debug output, I spotted the problem, which I’ve cut out into a smaller image:

The compositor was rejecting the render updates! I added this functionality during the rewrite to avoid rendering before objects got sized initially, so it was obvious to me what was occurring in the pipeline at this point:

  1. Client appears
  2. Client resizes
  3. Client runs its render update
  4. Client attempts to trigger rendering on itself
  5. Client fails to trigger rendering on itself
  6. Client shows
  7. Idle

No further render updates were pending, so the rendering never occurred even though all the information for the render was available. As proof, here’s what would happen when I moved the cursor over the area occupied by the non-rendered window:

Tada, the menu appears because it received damages and triggered more render updates:

Lots of render updates, in fact; there may be some overdraw here which can be eliminated at some point.

The STUNNING Conclusion:

After checking on a few things internally, I confirmed that events were occurring as I previously hypothesized, which meant that I just had to add in a flag to track when a client was ready for rendering and then add a render update when that client was shown if the flag was set. The entire commit was ~10 lines of changed code, and now things render as expected.

Afterthoughts:

This ended up being a relatively easy “hard” bug since render debugging is very informative, but it may give some insight as to how the process works.