Closed Bug 317447 Opened 19 years ago Closed 3 years ago

Plugins don't paint when calling RenderOffscreen

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Cleaned up, pulled common calls into helper function
18.73 KB, patch
Details | Diff | Splinter Review 
The nsObjectFrame.Paint() method gets called from RenderOffscreen and only paints windowless plugins. When using RenderOffscreen we need to pass the DC for the surface we are painting to to the plugin so it can paint there instead of to it's own window.

This shows up when using Canvas to render a page, as Canvas calls RenderOffscreen.
Uses a bunch of the printing code earlier in Paint(), might be good to pull some of that out into a helper function.
The revised patch I mentioned above. It pulls the code we need to run for printing to a different context from Paint() into a helper function.

There is still code that gets duped from the print-related section, but the way the Paint() method is structured I don't see an easy way to fix it without combining the sections of that method that deal with actually printing and the sections dealing with painting to the screen.

It does look like we might be able to get Mac's using this patch as well by adding them to the section lower in the method where I added the handling for different contexts. Since I don't have a mac to test on I didn't add it out of hand but will if someone more familiar with this code thinks it will work (and we can find a mac user to test). The Unix case doesn't look like it will work like this though, since on unix we dump a postscript file.
Attachment #204005 - Attachment is obsolete: true
Blocks: 319340
Just a note as I've finally tried this patch with a quicktime plugin (http://www.apple.com/trailers/fox/x3/). No worky. Apparently quicktime doesn't print the image area when responding to a print message. (I was able to get it playing with the patch to bug 319340, so there should have been content there)
+                         nsPresContext *aPresContext,

You don't need this parameter. Get the prescontext from the frame.

+                             nsPluginWindow &aPlugWin,
+                             nsPluginPrint  &aPlugPrint,

Make these pointers

+                             nsIPluginInstance *&aPlugInstance

Make this a **

+    /* XXXjgaunt - commenting this out because we lost the frame in re-factoring.
+                 - and this seems like a silly thing to do anyway. 

No, we need this. See bug 266933.

-  if (NS_FRAME_PAINT_LAYER_FOREGROUND == aWhichLayer) {

are you now painting in the background and float layers too?


(In reply to comment #4)
> +                         nsPresContext *aPresContext,
> 
> You don't need this parameter. Get the prescontext from the frame.
True, but is a method call better than just passing an extra param? aPresContext is passed into Paint, so we already have it. Just trying to avoid another method call.
> 
> +                             nsPluginWindow &aPlugWin,
> +                             nsPluginPrint  &aPlugPrint,
> 
> Make these pointers
Okay.

> 
> +                             nsIPluginInstance *&aPlugInstance
> 
> Make this a **
Okay, the file's precident is to use this format so I just went with it.

> 
> +    /* XXXjgaunt - commenting this out because we lost the frame in
> re-factoring.
> +                 - and this seems like a silly thing to do anyway. 
> 
> No, we need this. See bug 266933.
I looked at that bug and wasn't clear about the relation. That bug was about returning early during windowless operation. But the reason I added that comment was so someone who knows more about it can comment, so if you say so, it stays (just double checking :-) )

> 
> -  if (NS_FRAME_PAINT_LAYER_FOREGROUND == aWhichLayer) {
> 
> are you now painting in the background and float layers too?
> 
I added this because this was the layer that worked to get the plugin painting. The other layers did nothing (at least for Flash). I'm not entirely clear on the relevance, outside of understanding the difference between background, foreground and float. Now that you mention it I may go ahead and test this with the other layers and see if Quicktime works that way (not expecting it to) since  it doesn't currently work with this patch.

I'll make the changes and find you on IRC to chat about the layer stuff and the other issues.

(In reply to comment #5)
> (In reply to comment #4)
> > +                         nsPresContext *aPresContext,
> > 
> > You don't need this parameter. Get the prescontext from the frame.
> True, but is a method call better than just passing an extra param?
> aPresContext is passed into Paint, so we already have it. Just trying to
> avoid another method call.

I think that shrinking the interfaces between functions trumps saving a method call.

You may want to wait until I've landed frame display lists, which changes the way layering works.
While the head-fake we give the plugin in the patch by telling it to print to the new location works for Flash I've already found that it doesn't work for Quicktime. Can we get some plugin vendors represented in this bug to comment on "good" or "proper" ways to get their plugin to do what we want?

At least on windows it looks like we should be able to send a WM_PRINTCLIENT message to the window with the new DC and it should do the trick. But neither Flash nor Quicktime respond to this message. WM_PAINT unfortunately doesn't allow for different DC handles to be passed in.

Also, ROC can you add the dependancy to your layout DisplayItem bug?
Maybe you should poke/ask around to see if there is any way we can get Quicktime to paint to our DC.
Depends on: 317375
adding jst per chofmann's suggestion to bring in some plugin help.
Adding Michelle to try and get some input from Macromedia.

Michelle, in short, this patch tells the Flash plugin to print in order to get rendering in a different DC. Does the Flash plugin handle the WM_PRINT_CLIENT message at all? Can it be made to? Is there a better way from a Flash perspective?

> While the head-fake we give the plugin in the patch by telling it to print to
> the new location works for Flash I've already found that it doesn't work for
> Quicktime.
That's not our fault because we can't even actually print QuickTime movie. It's a QuickTime's bug (or intentional behaviour to prevent capturing copyrighted material).
The Flash Player does not respond to the WM_PRINT_CLIENT event. (Is this the correct naming of the event? I find no google hits on this.)

Right now, in released Flash Player versions, the only way the browser can get the Flash Player to print is via NPP_Print(). But, even in NPP_Print(), the Flash Player won't print anything if it is being used as a transparent plug-in.

I'll try to see if I can come up with other ideas for this, but for existing Flash Player versions, I think you may be out of luck.
Whoops, the actual message is WM_PRINTCLIENT.

The ideal goal is to get the plugins to let us tell them to print to somewhere other than the main window they are associated with. So on windows we have another DC we want to draw to. We can send that in the WM_PRINTCLIENT message, but not in the WM_PRINT message (we can send it but it is not really supported/defined). If we can come up with a better way to do this that works across platforms that would be ideal. So maybe we should consider an extension to the NPAPI. For windows there is a mechanism to do this (WM_PRINTCLIENT) but the plugins don't respond to this message.

I haven't even begun to look at what happens on mac and linux yet. (is there Flash & Quicktime on Linux even?)
The Flash Player doesn't support WM_PRINTCLIENT currently.

If you do explore an addition to the plug-in API, you are probably aware of the mailing list for this: plugin-futures@mozilla.org

Yes, the Flash Player supports Linux.
(In reply to comment #14)
> The Flash Player doesn't support WM_PRINTCLIENT currently.
> 
> If you do explore an addition to the plug-in API, you are probably aware of the
> mailing list for this: plugin-futures@mozilla.org

Has there been any more discussion about this?  Is there an archive for the plugin-futures list?
Dunno. jst is our interface to that process.
With Flash 9 now available for Linux and FF3a4 just released, has there been any movement towards fixing this issue?  Judging by the long CC list and the growing number of extensions that render web pages to the canvas, its seems a worthwhile effort.  A linux patch, at least to handle Flash, is what I would be most interested in.
In bug 137189 we're working on support for windowless mode in Linux. That might be extensible to help in this situation.
Perhaps the OS setting on this bug should be changed from WinXP to all?
John, were you planning to update this sometime?
Version: 1.8 Branch → Trunk
For windowed plugins on Linux, perhaps we could do something similar to QX11Mirror:
http://zrusin.blogspot.com/2007/06/mirroring-widgets.html

I don't know how QX11Mirror works, but I wonder whether it may be possible to register for painting events on the plugin window in the same way as a compositing window manager.
That's how QX11Mirror works --- the XDamage and XComposite extensions. It may be quite a lot of work to integrate windowed plugins into, though (although valuable work, since it would be really useful for regular browsing too).
It's also not clear whether the X server(s) used on various devices even support those extensions.
On Windows XP and later I think we can solve this using the PrintWindow API.
QA Contact: ian → layout.view-rendering
Component: Layout: View Rendering → Layout: Web Painting

We're in the process of removing support for plugins (bug 1677160), so I think this bug is irrelevant now.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: