Re: [RFR] [openjfx12] 8148129: Implement Accelerated composition for WebView

[Kevin Rushforth]

Thanks for the heads-up.

-- Kevin


On 9/4/2018 10:37 PM, Arunprasad Rajkumar wrote:

It is been merged with develop branch[1]. I’m planning to merge the patch to 
jfx-dev[2] mercurial branch as well.

[1] 
https://github.com/javafxports/openjdk-jfx/commit/9d16a90f2a3b79622ea834d9b5a0e1ed9f2779dc
[2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt

Thanks,
Arun



On 25-Aug-2018, at 12:25 PM, Arunprasad Rajkumar 
 wrote:

Hi,

Please review the patch for following enhancement, it is targeted for openjfx12.

https://bugs.openjdk.java.net/browse/JDK-8148129

Changes are available as gihub PR, refer the following link,

https://github.com/javafxports/openjdk-jfx/pull/51

Unified diff is available in the following link,

https://github.com/javafxports/openjdk-jfx/pull/51.diff

Thanks,
Arun

[RFR] 8210218: WebKit build fails with newer versions of VS 2017

[Arunprasad Rajkumar]

Hi Kevin, Johan,

Please review the following PR.

https://github.com/javafxports/openjdk-jfx/pull/200

Thanks,
Arun

Re: webkit feedback calls on failure

[Arunprasad Rajkumar]

Hi Johan,

Thanks for reporting this. I agree, there are few areas which needs improvement 
in WebView component, error handling is one among them. Please file a bug.

Regards,
Arun

> On 04-Sep-2018, at 7:01 PM, Johan Vos  wrote:
> 
> The WebEngine already allows to get information about the progress of the
> underlying webkit via the onError() handler and the getLoadWorker() status
> updates.
> 
> However, there are a number of cases where things go wrong in webkit, yet
> the status of the loadWorker is SUCCEEDED and no WebErrorEvent is generated.
> 
> A simple case is where a small html page loads a large image. In this case,
> URLLoader will call twkDidFinishLoading() which is a native call, which in
> turn will invoke ImageDecoderJava.cpp::setData
> 
> This call will invoke
> WCImageDecoderImpl.addImageData (back in the java layer), but when that
> throws a throwable (which it does, an OOME in resizeDataArray), it will
> ignore it by calling CheckAndClearException (in ImageDecoderJava.cpp) and
> the information about the exception is lost (that
> is, env->ExceptionDescribe() is called which will print thread + exception,
> but that's it).
> 
> Hence, at this moment it seems impossible to detect a failure when large
> images are loaded. While the status of the loadWorker will move to
> SUCCEEDED, the image won't be shown.
> 
> There are a number of ways to improve this, so if it is agreed that this
> can be an enhancement, I'll file an issue for it.
> 
> - Johan