A bug I repored to nvidia and intel driver developers some time ago seems to be harder to fix than I thought.
For composition where the source is read outside of its surface bounds, the result should be transparent (not touching the background), but instead its black for SRC, when src is a RGB24 picture:
In the short term both, intel and nvidia driver will fallback to software in this case because hardware does not seem to support it directly. I hope soon workarrounds will be implemented (in theory the driver would only have to allocate a ARGB32 picture, blit to that and use that one instead - maybe it could be done even more efficient with shaders). In the meantime I fight with building xorg from git ;)
Thanks a lot to Carl Worth for looking deeper into this issue! At least i965 and higher support the required behaviour and Carl fixed the driver, I filed a bug about it on 915 and lower. There are workarrounds which would solve it on that hardware too (if there should really be no support for it), however they are more than a 1:1 mapping and only apply in special cases. Using a temporary ARGB32 surface (maybe with tiling for very large source-pictures) is somewhat inefficent but should solve all cases.
A lot of interesting stuff is happening in the JVM space:
- The new G1 "Garbage First" garbage collector has been open-sourced
- IBM's Java got a cache for JITed and AOT code, I hope Hotspot will soon have a compareable feature too.
- 64-bit client jvm is almost ready
- Tired compilers are working
- CompressedOops reduce overhead on 64-bit platforms, when heap < 32GB
No idea what will be ready for JDK7, but this definitivly will be an interesting release again :)