Closed Bug 521940 Opened 15 years ago Closed 15 years ago

Flicker of background color on loading windowed plugins

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.3a1

People

(Reporter: karlt, Assigned: karlt)

References

Details

Attachments

(1 file, 1 obsolete file)

don't paint the socket window
2.20 KB, patch
roc
: review+
Details | Diff | Splinter Review 
Before the plugin gets a chance to draw into its Window, the background of the
(parent) Window from the GtkSocket is painted when this Window is mapped and
flushed.  This background depends on the GTK theme.

This causes a flicker visible even with in-process plugins,
such as when reloading
data:text/html,<body style="background:black"><embed type="application/x-test" width="300" height="500" wmode="window" drawmode="solid" color="000000"/>
or
data:text/html,<body style="background:white"><embed type="application/x-print-unix-nsplugin" width="300" height="500"/>

The background is very visible on first load with out-of-process plugins such
as the Java plugin from sun-jdk 1.6.0.15. e.g. on
http://java.sun.com/products/plugin/1.5.0/demos/plugin/applets/GraphLayout/example1.html
Attached patch first attempt (obsolete) — — Splinter Review 

    
    

    
  
In the first attempt, instead of the server painting the socket Window
immediately, the client paints when a GDK_EXPOSE event is received.  The paint
delay seemed long enough for in process XEmbed and and even Xt plugins (where
plug and socker are on different Display connections in the same process), but
the background was still very visible with the java plugin (on
mozilla-central), and flicker was still present with the test/sample plugins
out-of-process with electrolysis.

    
    

    
  


  
This always avoids the flicker from from the GtkSocket Window because the
Window is never painted.  Instead, we rely on the plug Window to cover the
socket Window.

(There is still a much smaller flicker remaining but that is from the way that
the plugins manage their windows and drawing.  The java plugin uses a
background of 0x00dfdfdf for its parent "Content window" and 0x00ffffff for
its child "sun-awt-X11-XPanelPeer" window, so there is flicker before the
child is mapped and when it is unmapped.  The x-test plugin draws to its plug
which has the background from the theme [but probably wouldn't have this
problem if it drew to a child widget].)

Perhaps, the ideal solution would have been to delay showing the
nsObjectFrame's widget until the plug window is mapped.  That way the content
underneath the plugin could be painted should an expose event occur while
waiting for the plug to be mapped.  However, tracking the state of the child
window is a little complex, requiring waiting for more X events, further
delaying the showing of the plugin.  (When the plug is attached to the socket,
the plug window is not mapped.  The plug seems to request that it be mapped and the socket responds by mapping it, like a window manager.)

        Attachment #405969 -
        Attachment is obsolete: true

        Attachment #405970 -
        Flags: review?(roc)

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/cfd9f1028de8
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1

    
  
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: