Add graphics layer support for plugins on symbian.
Created attachment 87462 [details] Implement graphics layer support for plugins on symbian.
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.
Created attachment 87465 [details] Fix style
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.
(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 ;)
Created attachment 87556 [details] Updated patch proposal
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
Created attachment 91306 [details] Updated patch
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?
(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.
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.
The CC'd folks should know about accellerated compositing and PlatformLayer (to tell if this patch makes sense).
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.
(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.
(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.
(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.
(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.
> > > > 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
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.
Created attachment 95016 [details] Updated patch
Comment on attachment 95016 [details] Updated patch LGTM, r+.
Comment on attachment 95016 [details] Updated patch Clearing flags on attachment: 95016 Committed r88816: <http://trac.webkit.org/changeset/88816>
All reviewed patches have been landed. Closing bug.
Revision r88816 cherry-picked into qtwebkit-2.2 with commit 7a6f64d <http://gitorious.org/webkit/qtwebkit/commit/7a6f64d>