JDK-6541868 : RFE: hardware acceleration for advanced blending modes (aka PhotoComposite)
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-04-03
  • Updated: 2019-12-17
  • Resolved: 2019-12-17
Related Reports
Relates :  
JDK-5094232 - RFE: New compositing modes for java2d (add, sub, div, mult)
Relates :  
JDK-6531647 - OGL: accelerate antialiased rendering for all AlphaComposite modes
Description
A DESCRIPTION OF THE REQUEST :
I would like to know if there are plan on introducing additional blending modes such as (overlay, multiply, divide, lighten, darken, ...) to the hardware accelerated features (via OpenGL or DirectX pipelines).

For applications requiring more complex blending modes than Porter-Duff rules implemented in the AlphaComposite, the current solution of manually implementing them is not satisfying because it breaks the hardware acceleration...
Hope you will make it  for java 7.

JUSTIFICATION :
The classics Porter-Duff rules are quite limited and it would be nice to have other blending modes prensent in Photoshop or Gimp and benefits from the hardware acceleration pipelines.
Comments
EVALUATION Shortly after writing the initial evaluation for this RFE back in April 2007 I did more prototyping on the OGL/D3D implementations of PhotoComposite. While it is indeed possible to accelerate those advanced blending modes using shaders, it necessarily requires reading portions of the destination (framebuffer) into a temporary texture since a) compositing operations in Java2D happen between an arbitrary source and the contents of the destination surface and b) the destination pixels are not directly accessible by a pixel shader in either OGL or D3D. This step of copying destination pixels into a temporary surface is relatively fast since it is a VRAM->VRAM operation, but it is less than ideal and requires adding a bunch of complex code to the hardware pipelines in Java2D. Also, since this RFE was first filed we have since delivered the Blend effect as part of JavaFX, which offers all of the blend modes originally proposed for PhotoComposite in a form that is much more easy to accelerate because the Blend inputs do not involve the destination (framebuffer), i.e. they are already available as source textures. I think these blend modes are better provided as a high-level effect rather than trying to shoehorn them to work with the existing Composite API in Java2D. Therefore, my current inclination is to scale back the changes originally proposed for JDK 7 and instead make small additions to the existing AlphaComposite API with at least an ADD mode since a) that is the most commonly requested blend mode that isn't already provided in AlphaComposite, b) it fits in fairly well with the existing AlphaComposite rules, and c) it can be accelerated easily in both the software and hardware pipelines (without the use of shaders or reading back from the framebuffer in the hardware case). We might also be able to add a simple MULTIPLY mode, but that will require some more investigation. I think this approach (small enhancements to AlphaComposite) would serve the needs of Java2D developers quite well, while keeping the implementation burden low. Developers who want access to extended blend modes can use the Blend class from JavaFX, which offers the right amount of functionality in a form that can be easily accelerated on the GPU.
13-02-2009
EVALUATION Yep, this is planned for JDK 7. In fact, most of the groundwork is already in progress and/or complete. First we need to get the new PhotoComposite API integrated with functional software loops (see 5094232), then the changes in 6531647 will lay the foundation for PhotoComposite acceleration for the OGL pipeline. Around that same time we should have the new D3D9 pipeline in place, and we can add acceleration for PhotoComposite for that pipeline as well.
03-04-2007