Bug 99722

Summary:

[Qt][WK2] Plugins are overscaled with a custom devicePixelRatio

Product:

WebKit

Reporter:

Balazs Kelemen <kbalazs>

Component:

Plug-ins

Assignee:

Balazs Kelemen <kbalazs>

Status:

RESOLVED WONTFIX

Severity:

Normal

CC:

abecsi, allan.jensen, cgarcia, hausmann, jturcotte

Priority:

Version:

528+ (Nightly build)

Hardware:

Unspecified

OS:

Unspecified

Attachments:

Description	Flags
Patch	kbalazs: review-

Balazs Kelemen

Reported 2012-10-18 08:14:15 PDT

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.

Attachments
Patch (1.60 KB, patch) 2012-11-28 09:59 PST, Balazs Kelemen	kbalazs: review-	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Balazs Kelemen

Comment 1 2012-10-29 10:52:55 PDT

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 ;)

Balazs Kelemen

Comment 2 2012-11-28 09:59:05 PST

Created attachment 176504 [details] Patch

Allan Sandfeld Jensen

Comment 3 2012-12-05 01:28:37 PST

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?

Balazs Kelemen

Comment 4 2012-12-05 01:50:31 PST

(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.

Jocelyn Turcotte

Comment 5 2012-12-05 05:59:56 PST

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.

Note You need to log in before you can comment on or make changes to this bug.