Context: bug 98518. This can be seen in MiniBrowser since we use a custom 1.5 devicePixelRatio. If I just make PluginProxy::contentsScaleFactor() return constant 1 it fixes this but we need to understand why, and where is the actual bug or the between us and mac.
I have problems with trying this on Mac. The idea of mine was to disable AC in MiniBrowser to trigger the actual code path that is causing the issue for us. Unfortunately I cannot make MiniBrowser use the PluginProcess of my build, for some reason it always use the one installed on the system. run-safari does not show any video for me (probably because I am using vnc, although MiniBrowser is playing them finely). I would appreciate if some of you who have direct access to a Mac could take a try with this ;)
Created attachment 176504 [details] Patch
I think this important for 5.0. I am also concerned were the bug really is at. Isn't part of the point of devicePixelRatio that content such as text could be rendered at a higher resolution instead of being image scaled? Could it somehow be that we forget to report the correct size of the rendered plugin output?
(In reply to comment #3) > I think this important for 5.0. I am also concerned were the bug really is at. > > Isn't part of the point of devicePixelRatio that content such as text could be rendered at a higher resolution instead of being image scaled? Could it somehow be that we forget to report the correct size of the rendered plugin output? Although I don't have full understanding of how devicePixelRatio is and should handled, I can say this patch avoids the image scaling, and the plugin size is ok. Actually I cannot follow the logic in PluginProxy, or rather I believe it is wrong. Furthermore that code path is not tested since Mac is using the AC path for plugins, Gtk doesn't support devicePixelRatio yet, EFL doesn't support plugins yet.
The problem might be that we apply the scaling once more when we blit the already scalled plugin backing store onto our non-composited-content tiles. The real solution I think would be to get plugin backing stores rendered using AC, passed through a ShareableSurface. It is pretty innefficient to blit it again on tiles using the CPU for each update by the plugin. I think that we can live with this bug until then, I don't see any real-world use case where we would want a WebView with both plugins and a non-1.0 device pixel ratio. It just happens to be the default (for testing purposes) in MiniBrowser.