[webkit-gtk] Public API to allow setting AC mode on a permanent basis for a WebView

[Carlos Garcia Campos]

El vie, 23-10-2015 a las 16:41 +0100, Mario Sanchez Prada escribió:
> Hi,
> 
> I recently spent some time debugging a few weird issues ([1],[2] and
> [3]) I
> was seeing in a local application and, after some digging, realized
> that
> some of them started happening in 2.8.x because of two main factors:
> 
>  * Before 2.8, PageClient's callbacks to enter/exit AC mode were no-
> ops
> 
>  * Because of the heavy usage of CSS animations in my local app,
> WebKit
>    was very often exitting & re-entering AC mode, which caused some
> rough
>    animations along the way (and even really bad graphics corruption
> [1])
> 
> Now those main problems are gone (thanks Carlos for your patch!) but
> smoothness in that app is not as good as it could be if AC mode was
> not
> continuously exitting/leaving, as I could check by simply putting
> this at
> the beginning of my main HTML file and keeping it there all the time:
> 
>     <div style="transform: rotateX(0deg);"></div>
> 
> This dummy CSS 3D animation ensures that WebKit is always in a state
> that
> requires AC mode on, preventing it from leaving that mode when the
> result of
> an animation would suggest so, resulting in a much smoother
> experience.
> 
> And that smoother experience, while noticeable in the device I was
> testing
> (and Intel Celeron N2807), it's even much more noticeable when I try
> it in a
> less powerful ARM box, so I think it's worth considering doing
> something.
> 
> So, my PROPOSAL would be to create a **new public API** in
> WebKit2GTK+ that
> would allow, through a WebKitSetting property, to tell WebKit to keep
> AC
> mode ON all the time to prevent this crazy dance of exitting & re-
> entering
> AC mode for cases (normally in controlled environments) where we know
> in
> advance it's going to happen.
> 
> So, what do you think? Any comment?

I have also WebKit patched to enforce AC mode in an embedded project
for exactly the same reason. I didn't propose this API because, as
Michael said, our plan has always been to switch to AC mode always on
unconditionally. However, I'm not sure we are ready for that yet. At
least now we support HiDPI in AC mode. My main concern are the graphics
drivers that can easily affect the performance, rendering correctness
or even stability. So, having a way to be able to turn it on/off at
runtime could be useful until we are confident enough to switch to AC
mode. Maybe adding API that we know we are going to deprecate at some
point is not a good idea, though. So maybe we can use any other way to
change that at runtime without using the API, like using an env var or
something like that. It would still be disabled by default, but in
embedded environments where we "trust" the graphics driver and we know
that switching between AC and non AC mode affects the application, we
can turn it on without patching WebKit.

Another interesting thing that we could allow applications to change is
the frame rate used for AC. 60 fps could be too much in some cases.
Again in embedded envs, we can safe resources by lowering the frame
rate while still having smooth animations.

> Thanks,
> Mario
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=150323
> [2] https://bugs.webkit.org/show_bug.cgi?id=150344
> [3] https://bugs.webkit.org/show_bug.cgi?id=150365
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk
> 
-- 
Carlos Garcia Campos
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.webkit.org/pipermail/webkit-gtk/attachments/20151026/33b22b00/attachment.sig>