WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 131562
[GTK] Add HighDPI support for non-accelerated compositing contents
https://bugs.webkit.org/show_bug.cgi?id=131562
Summary
[GTK] Add HighDPI support for non-accelerated compositing contents
Martin Robinson
Reported
2014-04-11 13:59:57 PDT
We need plumbing to route the scaling factor from GTK+ to WebCore.
Attachments
Patch
(17.09 KB, patch)
2014-04-11 15:07 PDT
,
Martin Robinson
no flags
Details
Formatted Diff
Diff
Rebased patch
(17.15 KB, patch)
2014-05-29 05:40 PDT
,
Carlos Garcia Campos
andersca
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Martin Robinson
Comment 1
2014-04-11 15:07:05 PDT
Created
attachment 229165
[details]
Patch
WebKit Commit Bot
Comment 2
2014-04-11 15:09:28 PDT
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See
http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Martin Robinson
Comment 3
2014-04-11 15:12:34 PDT
Owen, I made a few stylistic changes and moved the attachment of the property notify handler to webkitWebViewBaseCreateWebPage. This allowed me to transform the check for pageProxy into an assertion. Do you mind taking a quick look at the patch to see if I inadvertently introduced any non-cosmetic changes? :)
Owen Taylor
Comment 4
2014-04-11 15:41:06 PDT
As far as can tell from comparing the patches, the changes seem to be functionally equivalent.
Martin Robinson
Comment 5
2014-04-11 15:42:44 PDT
Okay. Thanks. I'll land this.
WebKit Commit Bot
Comment 6
2014-04-11 16:20:52 PDT
Comment on
attachment 229165
[details]
Patch Clearing flags on attachment: 229165 Committed
r167168
: <
http://trac.webkit.org/changeset/167168
>
WebKit Commit Bot
Comment 7
2014-04-11 16:20:56 PDT
All reviewed patches have been landed. Closing bug.
Carlos Garcia Campos
Comment 8
2014-04-12 02:14:07 PDT
Comment on
attachment 229165
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=229165&action=review
> Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp:973 > + ASSERT(priv->pageProxy);
This shouldn't happen, the signal is connected after creating the page and the page proxy is destroyed on finalize when the private struct is destroyed. If we want to be extra sure, we can save the signal handler and disconnect the signal on dispose since the page is closed there, any further call to page proxy after closed will be simply ignored.
> Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp:996 > + g_signal_connect(object, "notify::scale-factor", G_CALLBACK(scaleFactorChanged), NULL);
What is object here? does this even build? Use nullptr, instead of NULL.
Martin Robinson
Comment 9
2014-04-12 08:45:27 PDT
(In reply to
comment #8
)
> (From update of
attachment 229165
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=229165&action=review
> > > Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp:973 > > + ASSERT(priv->pageProxy); > > This shouldn't happen, the signal is connected after creating the page and the page proxy is destroyed on finalize when the private struct is destroyed. If we want to be extra sure, we can save the signal handler and disconnect the signal on dispose since the page is closed there, any further call to page proxy after closed will be simply ignored.
"This shouldn't happen" is precisely the situation to use an assertion in!
> > > Source/WebKit2/UIProcess/API/gtk/WebKitWebViewBase.cpp:996 > > + g_signal_connect(object, "notify::scale-factor", G_CALLBACK(scaleFactorChanged), NULL); > > What is object here? does this even build? Use nullptr, instead of NULL.
Ah, I let this one slip through. I can land a fix for it.
Philippe Normand
Comment 10
2014-04-13 04:11:26 PDT
Comment on
attachment 229165
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=229165&action=review
> Source/WebCore/platform/graphics/cairo/CairoUtilities.cpp:270 > + ASSERT_UNUSED(xScale, 1 == xScale);
Has this been tested in Debug builds? This ASSERT hits in the Debug bot, see
http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r167177%20(41643)/results.html
WebKit Commit Bot
Comment 11
2014-04-13 04:19:10 PDT
Re-opened since this is blocked by
bug 131589
Carlos Garcia Campos
Comment 12
2014-05-29 05:06:26 PDT
(In reply to
comment #10
)
> (From update of
attachment 229165
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=229165&action=review
> > > Source/WebCore/platform/graphics/cairo/CairoUtilities.cpp:270 > > + ASSERT_UNUSED(xScale, 1 == xScale); > > Has this been tested in Debug builds? This ASSERT hits in the Debug bot, see
http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r167177%20(41643)/results.html
The problem is that the tests can also set the device scale factor using WKPageSetCustomBackingScaleFactor, even if we don't set the intrinsic device scale factor to the web page proxy. So we might end up with a scaleFactor > 1 at any moment. We could make sure the custom scale factor is always 1 when hidpi is not supported for GTK+. I'll rebase the patch.
Carlos Garcia Campos
Comment 13
2014-05-29 05:40:35 PDT
Created
attachment 232244
[details]
Rebased patch
Anders Carlsson
Comment 14
2014-05-29 08:00:52 PDT
Comment on
attachment 232244
[details]
Rebased patch View in context:
https://bugs.webkit.org/attachment.cgi?id=232244&action=review
> Source/WebKit2/UIProcess/WebPageProxy.cpp:1853 > + return;
Like we discussed, please add a FIXME saying that this is only temporary.
Carlos Garcia Campos
Comment 15
2014-05-29 08:11:32 PDT
Committed
r169445
: <
http://trac.webkit.org/changeset/169445
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug