[Huawei Ideos X5 U8800] faekplastik3s:
Yeah, getting 4.4 on our device would actually be a decent test to see if the memory optimizations Google claims in 4.4 are significant (or just an adoption of the age-old community favorites like zRAM/ zSwap and some of the low-memory framework optimizations CM introduced lately), and if the value takes into account memory allocated to the GPU and other memory reserved components. Since there is still no stable CM as of yet, like you say, it's not really an option at this point. Still, if it ever happens, I guess you'd make the u8800 into the little device that could: 4.4, proper kernel and killer price! More than anything, I am looking forward to you finally figuring out a way to get rid of all these display issues, as they really are the only thing keeping me from making your ROM my daily driver.

EDIT: Whelp, off to testing!

EDIT 2: Since I don't want to double post, I'll leave my feedback here: this latest update didn't fix the display issues for me, and I have an Atmel digitizer so I can't vouch for the Synaptics issues. However, I did notice something new now that I hadn't before, and it's not because it is fixed or different, it is simply because I didn't realize it in previous versions:

The display issues happen all over the place: boot animation, the screen being cutoff when it finally boots into Android, the pin input screen, and so on. However, one good place to test is the browser, and that's where I also realized that display issues only seem to happen in here under specific conditions: for example, one annoying thing that makes the display issues a big deal for me is that keyboard prompts (as in, the big letter that appears when you press a keyboard key) get frozen (and not always frozen the same way, sometimes you see the whole prompt frozen, other times just part of it) until the screen refreshes (and it takes a long while). Now, if there is network access and search predictions are on (and the prediction box appears), the top row of keyboard buttons will glitch out, but the other rows will not. Not only that, the prompt will not fully glitch, only the top section, where it intersects with the prediction box (UI + a rather large offset). Not only that, but if there is no network access, the prediction box will not appear, and the keyboard will never glitch, not even the top row. Same if you type nonsense and it doesn't have a prediction to offer you. So, it only seems to glitch out when the keyboard prompt intersects with something else (a different view or overlay?)

Now, something different. For example, in the WiFi password screen, both the top and second row of keys will result in a glitch, but not the lower one. That is because the password input box is bigger than the prediction box in the browser (however, like before, the glitch occurs even if the prompt doesn't touch the box, as there is a fairly large offset), so part of the prompts of the second row reach the UI element and partly glitch out, while the top row fully glitches out. There also seems to be a clear "line" where the prompt starts to glitch, it doesn't seem random.

Not only that, but if, for example, you type a really large password in the WiFi password box and hold the delete key in the keyboard to continuously delete it, you'll see that the box doesn't update instantaneously, instead it takes ~4 seconds to finally render the deletion (there isn't a lag, it simply jumps to the current frame, so a bunch of text instantaneously disappears), then updates for a couple of frames more and the process repeats ad infinitum).

So, I don't know. Hope this helps, maybe it's related to some overlay optimization or something and this makes it easier to figure it out.