Closed Bug 530652 Opened 12 years ago Closed 12 years ago

Some sites not render flash

Categories

(Core :: Plug-ins, defect)

All
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta4-fixed
fennec 1.0+ ---

People

(Reporter: dougt, Assigned: dougt)

Details

Attachments

(1 file, 1 obsolete file)

On some sites, plugs are not rendered properly:

For example:

http://www.upscale.utoronto.ca/GeneralInterest/Harrison/Flash/Chaos/Bunimovich/Bunimovich.html


It looks like Paint() is being called.  We are short circuiting the slow Paint path and calling into NativeImageDraw().  The context that was passed isn't being written to and is garbage. 

Then we quickly blit to the screen using NativeImageDraw().  At which point, fennec's tiles are blitted to the screen.  This results in whatever was in the context.

We do not see any further invalidates.
Flags: blocking1.9.2?
Flags: blocking1.9.2? → blocking1.9.2+
tracking-fennec: --- → 1.0+
it looks like the front end can call setAbsoluteScreenPosition* when they notice a paint event pretty easily.
Attached patch patch v.1 (obsolete) — Splinter Review
1) no slow path at all on maemo now.
2) setAbsoluteScreenPosition will cause a native image draw.

This allows the front end to ensure that the plugin is painted.
Assignee: nobody → mozbugz
Attachment #414134 - Flags: review?
Comment on attachment 414134 [details] [diff] [review]
patch v.1

>@@ -4926,16 +4926,17 @@ void nsPluginInstanceOwner::Paint(gfxCon
>   PRBool simpleImageRender = PR_FALSE;
>   mInstance->GetValue(nsPluginInstanceVariable_WindowlessLocalBool,
>                       &simpleImageRender);
> 
>   if (simpleImageRender) {
>     gfxMatrix matrix = aContext->CurrentMatrix();
>     if (!matrix.HasNonAxisAlignedTransform())
>       NativeImageDraw();
>+    return;
>   }   

IMO it would be best to still draw to the tiles to reduce the flicker effect.  If this single draw is expensive, then I guess it's a choice between flicker and a bit of a delay, and I'll have to leave this choice to you.

>@@ -5887,11 +5888,12 @@ nsPluginInstanceOwner::SetAbsoluteScreen
>   UpdateVisibility();
>+  NativeImageDraw();

There should be NPPVpluginWindowlessLocalBool check in here somewhere.

>-  return NS_OK;
>-}
>-#endif
>+  return NS_OK;
>+}
>+#endif

Can't see any difference here.  I guess hg is just plain lazy.
Attached patch patch v.2Splinter Review
with fixes.

i do not think we need a slow paint path on maemo if the fe is going to be calling setAbsoluteScreenPosition more aggressively.
Attachment #414134 - Attachment is obsolete: true
Attachment #414158 - Flags: review?
Attachment #414134 - Flags: review?
Attachment #414158 - Flags: review? → review+
Attachment #414158 - Flags: approval1.9.2+
Check-in: http://hg.mozilla.org/mozilla-central/rev/8ca9facea08d
Check-in: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/df6f909d4797
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Hm, what you checked in doesn't match the attachment:
http://hg.mozilla.org/mozilla-central/rev/8ca9facea08d
    1.26 +  if (mInstance)
    1.27 +    NativeImageDraw();

should be if (simpleImageRender)
the v.2 patch was created for the mozilla 1.9.2 branch.  I needed to adjust it somewhat to apply to the trunk (there are a bunch of gratuitous name changes between 1.9.2 and mc).  I am pretty sure during this processes I introduced this mistake.  The mistake is not in the 1.9.2 code.  I have pushed a fix to m/c.  Thanks Christian for pointing out my mess!! ;-)

http://hg.mozilla.org/mozilla-central/rev/2bae3bbf866e
You need to log in before you can comment on or make changes to this bug.