1218688 - Remove unused synchronous plugin drawing paths

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

We have a synchronous drawing path for windowless plugins, possibly added during OOP development. It looks this involves creating a shared surface in SetWindow, then sending fake paint messages to the plugin during display list painting and waiting until each paint completes. On Windows, it paints twice for alpha extraction.

After talking to Jim and Bill, the synchronous code looks dead with OOP plugins, where we use async rendering instead. This involves a different SetWindow path - AsyncSetWindow - and a display item that creates an ImageLayer instead of painting on the main thread.

In theory we could ditch *all* of the synchronous rendering paths, since bug 1217665 removed in-process plugin support on Desktop. Except that we still use it for Flash when running specifically on Android 2.3.

Aside from that, we should be able to delete a whole bunch of code.

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 1, rm windows code

Comment 2

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 1, rm windows code

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 2, rm linux code

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 3, remove mac code

Comment 5

[Benjamin Smedberg]

Historically (IIRC) the sync drawing code came first and async rendering came after. But yes, we don't need to support that on Desktop any more. We do need Android to keep working though.

Comment 6

[David Anderson [:dvander] - inactive, e-mail if emergency]

Good to know - I'll leave the Android code alone then.

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 3, rm mac code

Benoit, context: I think this code is all related to synchronously painting plugins on Mac, and therefore dead. Seems green on Try.

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: part 4, assert no synchronous painting

Assert that on non-Android platforms, we do not try to paint a windowless plugin synchronously.

Comment 9

[Benoit Girard (:BenWa)]

Comment on attachment 8679658 [details] [diff] [review]
part 3, rm mac code

Review of attachment 8679658 [details] [diff] [review]:
-----------------------------------------------------------------

I think this code could still, in theory, be used by someone running 32-bit in-process legacy plugins.

That population may very well be zero and I don't think we should maintain this code patch. r+

Comment 10

[Benjamin Smedberg]

Comment on attachment 8679659 [details] [diff] [review]
part 4, assert no synchronous painting

FWIW, we stopped supporting in-process plugins on any desktop system (only Android).

Comment 11

[Jim Mathies [:jimm]]

Comment on attachment 8679324 [details] [diff] [review]
part 2, rm linux code

Review of attachment 8679324 [details] [diff] [review]:
-----------------------------------------------------------------

I can't believe all the nsPluginFrame painting code is finally going away. :) feels good to see it go.

Comment 12

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/fd4f3106204c
https://hg.mozilla.org/integration/mozilla-inbound/rev/34e7e1b81662
https://hg.mozilla.org/integration/mozilla-inbound/rev/314b650c9423
https://hg.mozilla.org/integration/mozilla-inbound/rev/7ad55e9ba985

Comment 13

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/fd4f3106204c
https://hg.mozilla.org/mozilla-central/rev/34e7e1b81662
https://hg.mozilla.org/mozilla-central/rev/314b650c9423
https://hg.mozilla.org/mozilla-central/rev/7ad55e9ba985