On Fri, 10 Sep 2021 18:15:21 GMT, Jose Pereda <jper...@openjdk.org> wrote:
>> Currently, `WebPage` has already a public `setBackgroundColor()` method, but
>> the class is not public. Therefore, public API is needed in `WebView` to
>> allow developers access to it.
>>
>> In line with the `fontSmoothingType` property, this PR provides public
>> support for setting the background color of a WebPage, by adding a
>> `pageFill` property, and a CSR is required.
>>
>> The color for the background, that can be opaque, transparent or with any
>> level of opacity, can be set via code or via CSS using `-fx-page-fill`.
>>
>> Unit tests and a system test are provided.
>
> Jose Pereda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix test to pass all 3 platforms
> Somehow by accident I've found out that doing in `WebPage::paint2GC`:
>
> ```
> + gc.clearRect(0, 0, 0, 0); // extra call to clear rect
> ```
>
> fixes the issue for the Group test (same for no container case).
Interesting.
> After some testing, I modified this method to get it working with the
> expected single call with just this change:
>
> ```
> - // set the blend mode to CLEAR
> - context.updateCompositeMode(CompositeMode.CLEAR);
> Paint oldPaint = getPaint();
> setPaint(Color.BLACK); // any color will do...
> fillQuad(x1, y1, x2, y2);
> + // set the blend mode to CLEAR
> + context.updateCompositeMode(CompositeMode.CLEAR);
> context.flushVertexBuffer();
> ```
>
> which seems to indicate that `fillQuad` requires SRC_OVER and we can use the
> original black color, and only before flushing we set the CLEAR mode.
Even more interesting.
> Does this make sense?
No, it doesn't make sense, since setting the mode to CLEAR before drawing the
quad is the right order. The fact that it matters indicates that something very
odd is happening with state management.
Your experiment was the clue that allowed me to figure out the problem. The
problem is that the call to `context.updateCompositeMode` is simply the wrong
thing to do. The right call, which is what the D3D pipeline is doing, is
`setCompositeMode`. The former does not update the state so any other method
that validates the state will use the wrong composite mode. It's amazing to me
that this went undetected for this long, and that it hasn't caused other
problems.
Here is the proposed change:
CompositeMode mode = getCompositeMode();
// set the blend mode to CLEAR
- context.updateCompositeMode(CompositeMode.CLEAR);
+ setCompositeMode(CompositeMode.CLEAR);
Paint oldPaint = getPaint();
setPaint(Color.BLACK); // any color will do...
fillQuad(x1, y1, x2, y2);
context.flushVertexBuffer();
setPaint(oldPaint);
// restore default blend mode
- context.updateCompositeMode(mode);
+ setCompositeMode(mode);
This will need to be well tested on Linux and Mac (a full set of Robot tests).
-------------
PR: https://git.openjdk.java.net/jfx/pull/563
