Bug 57418 – [Qt] [Symbian] GraphicsLayer: support plugins on symbian

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Viatcheslav Ostapenko]

Add graphics layer support for plugins on symbian.

[Viatcheslav Ostapenko]

Created attachment 87462 [details]
Implement graphics layer support for plugins on symbian.

[WebKit Review Bot]

Attachment 87462 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1

Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:113:  Missing space before ( in if(  [whitespace/parens] [5]
Total errors found: 1 in 3 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Viatcheslav Ostapenko]

Created attachment 87465 [details]
Fix style

[Benjamin Poulain]

Comment on attachment 87465 [details]
Fix style

View in context: https://bugs.webkit.org/attachment.cgi?id=87465&action=review

Is there no way to test this?
There are changes to PluginView which do not look Symbian specific, can't they be commited separately with test coverage?

> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:93
> +// Qt's GraphicsLayer (GraphicsLayerQt) requires layers to be QGraphicsWidgets

Missing dot at the end of the sentence.
Useless comment anyway, it does not add information/explanation, you can remove it.

> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:112
> +        clipRect.translate(-clipRect.topLeft());

That looks weird, are you trying to map and object from content coordinate to window coordinate?

> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:118
> +        rect.adjust(-1, -1, 1, 1);

WHAAAAAAAAT?
That deserve a comment :)

> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:484
> +            // Trigger layer computation in RenderLayerCompositor

Not period at the end of the sentence.
Useless comment anyway.

[Viatcheslav Ostapenko]

(In reply to comment #4)
> (From update of attachment 87465 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=87465&action=review
> 
> Is there no way to test this?
> There are changes to PluginView which do not look Symbian specific, can't they be commited separately with test coverage?

What is not symbian specific? Moving out m_platformLayer definition out of XP_UNIX ifdef? ;)
I have similar patch coming for windows, so all platforms should be covered.
In any case, having unused m_platformLayer member shouldn't harm.

> > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:93
> > +// Qt's GraphicsLayer (GraphicsLayerQt) requires layers to be QGraphicsWidgets
> 
> Missing dot at the end of the sentence.
> Useless comment anyway, it does not add information/explanation, you can remove it.

Copy paste from Linux patch ;)

> > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:112
> > +        clipRect.translate(-clipRect.topLeft());
> 
> That looks weird, are you trying to map and object from content coordinate to window coordinate?

Yes. What's weird here? It assigned from frameRect one line upper.
Would this

QRectF clipRect(m_view->frameRect().translated(-m_view->frameRect().topLeft()));

look better? ;)

> > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:118
> > +        rect.adjust(-1, -1, 1, 1);
> 
> WHAAAAAAAAT?
> That deserve a comment :)

It is converted from QRectF to QRect. I see artifacts with animated transparent plugins when QGraphicsWebView is scaled.
Here is sample: goo.gl/uhgYk

> > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:484
> > +            // Trigger layer computation in RenderLayerCompositor
> 
> Not period at the end of the sentence.
> Useless comment anyway.

Copy/paste again ;)

[Viatcheslav Ostapenko]

Created attachment 87556 [details]
Updated patch proposal

[Viatcheslav Ostapenko]

Comment on attachment 87556 [details]
Updated patch proposal

Need to update patch with fix similar to https://bugs.webkit.org/show_bug.cgi?id=34415

[Viatcheslav Ostapenko]

Created attachment 91306 [details]
Updated patch

[Alexis Menard (darktears)]

Comment on attachment 91306 [details]
Updated patch

View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review

> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:111
> +            clipRect &= option->exposedRect;

Just by curiosity, partial updates are worth it? Do you have a test case where it performs better for the plugin?

[Viatcheslav Ostapenko]

(In reply to comment #9)
> (From update of attachment 91306 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review
> 
> > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:111
> > +            clipRect &= option->exposedRect;
> 
> Just by curiosity, partial updates are worth it?

Why not? ;)

> Do you have a test case where it performs better for the plugin?

Flash plugins could be quite big - bigger than screen size. It makes difference even for simple bit blit. From previous measurements full screen bit blit without alpha on N97 was taking about 12ms. If plugin is bigger, or alpha blending involved, than it will be longer.

[Eric Seidel (no email)]

Comment on attachment 91306 [details]
Updated patch

View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review

> Source/WebCore/plugins/PluginView.h:432
> +#if USE(ACCELERATED_COMPOSITING) && (defined(XP_UNIX) || OS(SYMBIAN))

Why the unix here?

> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:472
> +        if (m_parentFrame->page()->chrome()->client()->allowsAcceleratedCompositing()
> +            && m_parentFrame->page()->settings()
> +            && m_parentFrame->page()->settings()->acceleratedCompositingEnabled()) {

I wonder if this shouldn't be a helper function.

[Eric Seidel (no email)]

The CC'd folks should know about accellerated compositing and PlatformLayer (to tell if this patch makes sense).

[Alexis Menard (darktears)]

Comment on attachment 91306 [details]
Updated patch

View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review

>> Source/WebCore/plugins/PluginView.h:432
>> +#if USE(ACCELERATED_COMPOSITING) && (defined(XP_UNIX) || OS(SYMBIAN))
> 
> Why the unix here?

+1

>>> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:111
>>> +            clipRect &= option->exposedRect;
>> 
>> Just by curiosity, partial updates are worth it? Do you have a test case where it performs better for the plugin?
> 
> Why not? ;)

Because computing the exposed rect may be costly in QGV.

[Viatcheslav Ostapenko]

(In reply to comment #11)
> (From update of attachment 91306 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review
> 
> > Source/WebCore/plugins/PluginView.h:432
> > +#if USE(ACCELERATED_COMPOSITING) && (defined(XP_UNIX) || OS(SYMBIAN))
> 
> Why the unix here?

Because this patch adds AC plugin layer implementation for symbian to already existing unix implementation. Mac and windows still do not have plugin AC layer implementation for Qt. I just modified existing ifdef (added SYMBIAN).
It's a bit unclear, because I had to break previous #ifdef at line 429 (paintUsingXPixmap is not needed on symbian and other platforms).

> 
> > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:472
> > +        if (m_parentFrame->page()->chrome()->client()->allowsAcceleratedCompositing()
> > +            && m_parentFrame->page()->settings()
> > +            && m_parentFrame->page()->settings()->acceleratedCompositingEnabled()) {
> 
> I wonder if this shouldn't be a helper function.

What exactly? Big condition or creating of plugin layer? Or both together? ;)
In any case, I'd prefer to leave it as it is to make it similar to unix implementation to make later merging of other changes simpler.

[Eric Seidel (no email)]

(In reply to comment #14)
> (In reply to comment #11)
> > (From update of attachment 91306 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review
> > 
> > > Source/WebCore/plugins/PluginView.h:432
> > > +#if USE(ACCELERATED_COMPOSITING) && (defined(XP_UNIX) || OS(SYMBIAN))
> > 
> > Why the unix here?
> 
> Because this patch adds AC plugin layer implementation for symbian to already existing unix implementation. Mac and windows still do not have plugin AC layer implementation for Qt. I just modified existing ifdef (added SYMBIAN).
> It's a bit unclear, because I had to break previous #ifdef at line 429 (paintUsingXPixmap is not needed on symbian and other platforms).

Sounds like we might want to come up with a new define then.  Otherwise we're going to have to add defined(WIN) || everywhere when we add win, and then again fo mac, etc.

> > 
> > > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:472
> > > +        if (m_parentFrame->page()->chrome()->client()->allowsAcceleratedCompositing()
> > > +            && m_parentFrame->page()->settings()
> > > +            && m_parentFrame->page()->settings()->acceleratedCompositingEnabled()) {
> > 
> > I wonder if this shouldn't be a helper function.
> 
> What exactly? Big condition or creating of plugin layer? Or both together? ;)
> In any case, I'd prefer to leave it as it is to make it similar to unix implementation to make later merging of other changes simpler.

Well, consider this example:

if (shouldUseAccelleratedComposititing(m_parentFrame))

Such is very clear at the call site what it does.  And the actual implementation of the check can use local variables and early return as well.

I'm not saying that splitting ifs off into functions is always a good choice.  But in this one, I think it might be, given all the m_parentFrame->paget()->chrome copy paste.

[Viatcheslav Ostapenko]

(In reply to comment #13)
> >>> Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:111
> >>> +            clipRect &= option->exposedRect;
> >> 
> >> Just by curiosity, partial updates are worth it? Do you have a test case where it performs better for the plugin?
> > 
> > Why not? ;)
> 
> Because computing the exposed rect may be costly in QGV.

Costlier than blitting of the whole screen? ;)
I didn't test this implementation for performance, but in other browser on symbian there is clear difference for big plugins that do partial screen updates (like some animation running) on N8 with raster only flash plugin. Frame rate drops significantly and visually you can seed difference. With HW accelerated plugin difference is minmal (5% max for small animations on full screen plugin), but still exists.

[Viatcheslav Ostapenko]

(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #11)
> > > (From update of attachment 91306 [details] [details] [details])
> > > View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review
> > > 
> > > > Source/WebCore/plugins/PluginView.h:432
> > > > +#if USE(ACCELERATED_COMPOSITING) && (defined(XP_UNIX) || OS(SYMBIAN))
> > > 
> > > Why the unix here?
> > 
> > Because this patch adds AC plugin layer implementation for symbian to already existing unix implementation. Mac and windows still do not have plugin AC layer implementation for Qt. I just modified existing ifdef (added SYMBIAN).
> > It's a bit unclear, because I had to break previous #ifdef at line 429 (paintUsingXPixmap is not needed on symbian and other platforms).
> 
> Sounds like we might want to come up with a new define then.  Otherwise we're going to have to add defined(WIN) || everywhere when we add win, and then again fo mac, etc.

After mac and win AC plugin layers are implemented this condition can be removed because all 4 platforms will be supported.
 
> > > 
> > > > Source/WebCore/plugins/symbian/PluginViewSymbian.cpp:472
> > > > +        if (m_parentFrame->page()->chrome()->client()->allowsAcceleratedCompositing()
> > > > +            && m_parentFrame->page()->settings()
> > > > +            && m_parentFrame->page()->settings()->acceleratedCompositingEnabled()) {
> > > 
> > > I wonder if this shouldn't be a helper function.
> > 
> > What exactly? Big condition or creating of plugin layer? Or both together? ;)
> > In any case, I'd prefer to leave it as it is to make it similar to unix implementation to make later merging of other changes simpler.
> 
> Well, consider this example:
> 
> if (shouldUseAccelleratedComposititing(m_parentFrame))
> 
> Such is very clear at the call site what it does.  And the actual implementation of the check can use local variables and early return as well.
> 
> I'm not saying that splitting ifs off into functions is always a good choice.  But in this one, I think it might be, given all the m_parentFrame->paget()->chrome copy paste.

Yes, I've got it. Should I make it for linux part also? I'd like to keep it similar.

[Laszlo Gombos]

> > > > Source/WebCore/plugins/PluginView.h:432
> > > > +#if USE(ACCELERATED_COMPOSITING) && (defined(XP_UNIX) || OS(SYMBIAN))
> > > 
> > > Why the unix here?
> > 
> > Because this patch adds AC plugin layer implementation for symbian to already existing unix implementation. Mac and windows still do not have plugin AC layer implementation for Qt. I just modified existing ifdef (added SYMBIAN).
> > It's a bit unclear, because I had to break previous #ifdef at line 429 (paintUsingXPixmap is not needed on symbian and other platforms).
> 
> Sounds like we might want to come up with a new define then.  

Perhaps a local macro ?

#if PLATFORM(QT) && USE(ACCELERATED_COMPOSITING) && ENABLE(NETSCAPE_PLUGIN_API) && (defined(XP_UNIX) || OS(SYMBIAN))
#define WTF_USE_ACCELERATED_COMPOSITING_PLUGIN_LAYER
#endif

[Laszlo Gombos]

Comment on attachment 91306 [details]
Updated patch

View in context: https://bugs.webkit.org/attachment.cgi?id=91306&action=review

r- to make sure guards are used consistently.

>>>>>> Source/WebCore/plugins/PluginView.h:432
>>>>>> +#if USE(ACCELERATED_COMPOSITING) && (defined(XP_UNIX) || OS(SYMBIAN))
>>>>> 
>>>>> Why the unix here?
>>>> 
>>>> +1
>>> 
>>> Because this patch adds AC plugin layer implementation for symbian to already existing unix implementation. Mac and windows still do not have plugin AC layer implementation for Qt. I just modified existing ifdef (added SYMBIAN).
>>> It's a bit unclear, because I had to break previous #ifdef at line 429 (paintUsingXPixmap is not needed on symbian and other platforms).
>> 
>> Sounds like we might want to come up with a new define then.  Otherwise we're going to have to add defined(WIN) || everywhere when we add win, and then again fo mac, etc.
> 
> After mac and win AC plugin layers are implemented this condition can be removed because all 4 platforms will be supported.

This probably breaks the build when ENABLE(NETSCAPE_PLUGIN_API) is false. A local macro use consistently would help avoid making mistakes like this and would help with readability.

[Viatcheslav Ostapenko]

Created attachment 95016 [details]
Updated patch

[Laszlo Gombos]

Comment on attachment 95016 [details]
Updated patch

LGTM, r+.

[WebKit Review Bot]

Comment on attachment 95016 [details]
Updated patch

Clearing flags on attachment: 95016

Committed r88816: <http://trac.webkit.org/changeset/88816>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Ademar Reis]

Revision r88816 cherry-picked into qtwebkit-2.2 with commit 7a6f64d <http://gitorious.org/webkit/qtwebkit/commit/7a6f64d>