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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-gtk > -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
