anholt's lj

Making EXA go faster.
Bug #4668 makes my life hard.

The problem is that we don't expect to be able to do component alpha acceleration on most (any) drivers right now. I keep hoping we can make migration Do The Right Thing so that the software fallbacks aren't too bad, but it keeps failing to work (improve one case, degrade another). Currently gnome-terminal with subpixel fonts is the problem. After my last patch improved the situation a bit but left it still ~3 times worse than XAA, I turned on the migration debugging to see what was going on. It appears that gnome-terminal is creating a pixmap, rendering the terminal to it, then copying it to the screen. Then I guess it destroys and repeats for the next update. So you get creation, a few accelerated operations (push it into fb and dirty it), then piles and piles of unaccelerated text (pushing it back out -- huge CPU time hit). My last patch made it push back out faster, which helped, but the simple fact of pushing it out after dirtying in fb is the problem.

Now, I see an easy way to fix this. I just have to wait for some N operations before committing to letting something get dirtied in framebuffer. Only, then, resizing with a compmgr is going to suck because the first thing that happens in resizing is a copy from framebuffer into a fresh pixmap. If I don't let it get dirtied in fb then, it will be very painful.

One crazy idea might be to keep rendering which could be easily (as in, no reads from fb) done by the CPU being done in the system-memory copy as well. This way seems like madness.

Maybe we need to just deal with getting component alpha accelerated somehow. Time to go look at the math again and see what the best way is going to be...

Advertisement