For windowless plugins on mobile device it is important to know about their visibility state... For example if we have > 1 windows with various flash video or some other content, it would be nice to have some way to notify plugins are they visible or not. and plugins can decide to suspend some video decoding or switch games to pause state in case if they are on background (not visible window)... Currently I cannot find any existing code or API to implement such notifications... Can someone advice what is the best way to do that?
What about stuff like tab preview? Are you OK to display the old contents for hidden tabs?
You might not need a new API. On Mac OS X we send NPP_SetWindow(NULL) when hiding a plugin behind another tab, you may be able to send NPP_SetWindow(NULL) on Windows/Linux mobile in a different case, for overlapping windows (not just tabs).
(In reply to comment #1) > What about stuff like tab preview? Are you OK to display the old contents for > hidden tabs? I think it is ok, and it is more important to have better performance for current active page than update all the time all pages, and have whole device busy because all pages working, and rendering actively...
> You might not need a new API. On Mac OS X we send NPP_SetWindow(NULL) when > on Windows/Linux mobile in a different case, for overlapping windows (not just > tabs). Yep, I know that I can send some event to plugin... but I was thinking what the best way to do that: 1) Implement separate plugin enumerator for DOMwindow, and send event for each plugin. 2) Or attach all plugin objects in nsObjectFrame to some parent dom window event, then send event to window and all objects will handle it automatically
Created attachment 405139 [details] [diff] [review] Proposed fix, used in microb-engine for N900
Assignee: nobody → romaxa
Attachment #405139 - Flags: review?(roc)
Plugins in iframes won't hear about pluginsshow/pluginshide, right? Another way the plugin can detect visibility is by tracking paints and invalidates. Suppose it periodically invalidates itself completely every few seconds. If it gets no paint event, then it must be completely invisible. If it gets a paint event, it is probably visible and should come out of its suspended state. Would that work? That wouldn't require any browser changes.
Yes, we were considering this option in the beginning... I need to check with flash team again and recall why it was rejected.
We had some problem with additional timeouts creation and internal flash implementation. Theoretically it can be done: NPP_InvalidateRect (create timer for 5 seconds) ..... (If timer created just continue.) If timer finished and no Expose events came... then invoke suspend. I will create new bug about this problem... and check how fast we can try this approach.
Also with this new approach we should document it and make sure that all plugins have implemented this functionality... But most of plugins already handling VisibilityNotify signals (since windowed mode)... and with my patch it is very easy to port those plugins.
Also question is why MacOSX port using this implementation and not rely all responsibility to plugins?
(In reply to comment #9) > But most of plugins already handling VisibilityNotify signals (since windowed > mode)... and with my patch it is very easy to port those plugins. How many plugins really handle VisibilityNotify for this kind of optimization? (In reply to comment #10) > Also question is why MacOSX port using this implementation and not rely all > responsibility to plugins? I don't know, but we can't assume it's for this reason. They may need to know immediately when their window is hidden. Josh may know.
> How many plugins really handle VisibilityNotify for this kind of optimization? chicken and the egg. right now, flash on the n900 device and diamondx.
In comment #9 Oleg said > But most of plugins already handling VisibilityNotify signals (since windowed > mode)... and with my patch it is very easy to port those plugins. If "most plugins" just means Flash on the N900, then this isn't a very compelling argument.
roc/josh, what is needed here; what are the next steps?
It seems to me nothing is needed here, Flash can do this optimization itself as per comments #6 and #8.
wontfix. per #6 #8.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
this is required to get invalidation events from the flash plugin on the maemo platform. romaxa, can this be fixed on the plugin side before you ship? If now, we will need something in the browser as right now we do not receive any invalidation events.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Created attachment 407933 [details] [diff] [review] cleaned up patch -- minimum required. assuming that flash can not be fixed, would this be acceptable?
Comment on attachment 407933 [details] [diff] [review] cleaned up patch -- minimum required. This is pretty lame. It's not a very good visibility test --- it will report hidden tabs, scrolled out of view, etc, as visible --- but if it works for you, I can swallow it. Just promise me that Flash will get fixed and we can take this out.
Attachment #407933 - Flags: review?(roc) → review+
I am also unhappy with the change and hope that the plugin can be fixed before they ship.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago → 8 years ago
Resolution: --- → FIXED
Comment on attachment 407933 [details] [diff] [review] cleaned up patch -- minimum required. a192=beltzner
Attachment #407933 - Flags: approval1.9.2? → approval1.9.2+
status1.9.2: --- → beta1-fixed
You need to log in before you can comment on or make changes to this bug.