Hi, Now that pixman 0.16.0 is out, it's time to look at what comes next.
0.16.2 We'll need an 0.16.2 release to fix ARM, Solaris and Windows x64 build issues. People should feel free to push these fixes to master and cherry-pick them to the new 0.16 branch. Once we have all the fixes in, I'll make a 0.16.2 release. 0.17.x: There is a couple of patches (Chris' AM_SILENT_RULES patch and Joonas' fix for a1 trap sampling) that as far as I know are ready to go in. Feel free to push those to master. I don't expect to have a lot of time for pixman development myself for 0.17.x. The things I do plan to do are: - Look at Jeff's image scaling patch - Merge a couple of straight-forward performance fixes: - Andre's bilinear optimization - Unroll branch http://cgit.freedesktop.org/~sandmann/pixman/log/?h=unroll (unless this is superseded by macro based fast paths (see below)) - Enable disabled SSE2 fast path - Code review and releases as necessary. Other than that, for 0.17.x I hope people will look into getting some of the more straight-forward performance improvements in. I have included a non-exhaustive list of ideas below. There is also the newly updated list of pixman projects here: http://people.freedesktop.org/~sandmann/pixman-projects.html with some more blue-sky projects such as multithreading, polygon images and JIT compilers. Ideas for 0.17.x: - More architecture specific fast paths. - Siarhei has new NEON fast paths - Fast paths for other architectures is welcome too - Faster fast paths On some benchmarks _pixman_run_fast_path() shows up quite high. This branch: http://cgit.freedesktop.org/~sandmann/pixman/log/?h=faster-fast-path contains two straight-forward ideas: - It puts a cache in fron of _pixman_run_fast_path() - It computes the properties to match against up front instead of on each iteration. To make this mergable, we'll need configure time checks for thread local storage. - Even faster fast paths - Add negative caching (ie., cache the fact that we *didn't* find a fast path). Then make the cache cover all of the fast path tables so that only one cache look-up will be necessary per composite. - Treat general_composite() as a fast path that will always get hit. Then get rid of the implementation->composite() method and just have the implementations export a fast path table. - Use the preprocessor to make fast paths The idea is demonstrated here: http://cgit.freedesktop.org/~sandmann/pixman/commit/?h=macro-fast-path&id=c6442a16a64ea833c444a424d56fa9ae9c0f9e6a In that commit the macro is being used for fetchers, but I think the same idea may be applicable to full fast paths, including SIMD fast paths. Siarhei's scaling fast paths http://lists.cairographics.org/archives/cairo/2009-May/017211.html could probably be done this way too. - Text performance improvements. Software glyph rendering with X is rather slow. The most important fix here is to keep pixman_images around as private data attached to a Picture instead of creating three of them on each request. Even with that, it may make sense to add more explicit support for glyph rendering to pixman. A new pixman_glyphs_t data type along with a pixman_composite_glyphs_t() entry point to match the corresponding Render API might be useful. This will also allow us to make the cairo image backend significantly faster for glyphs. - Allowing implementations to plug in fetchers The idea is to virtualize images so that implementations can plug in their own scanline fetchers. This is needed to fix these bugs: https://bugs.freedesktop.org/show_bug.cgi?id=20709 https://bugs.freedesktop.org/show_bug.cgi?id=21173 that Steve Snyder filed. Gradients are another obvious application. Thanks, Soren _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel