Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] SWT browser

Hi Scott,

Fixing bug #337499 definitely fixed some issues I was experiencing with
mouse events in applets in the the Mac SWT browser. Mouseover events are now
delivered to the applet and it fixed a strange issue I was experiencing
where the embedded browser would fight with the surrounding web-page for
focus... neither winning.

I am still experiencing sluggishness in the embedded browser, though, in Plugin2.
Most notable is scrolling which is very delayed. The caret (blinking
vertical bar) does not blink, and typing is slightly delayed. Also, as you
mention below, Flash videos do not render.

Interestingly, Mac's Plugin1 (JavaPluginCocoa) does not experience any of
the issues above and does render Flash videos in the SWT browser.
My research and testing is telling me that Plugin1 renders the embedded
browser applet in a CALayer whereas Plugin2 embeds the browser applet in the
legacy NSView. NSView uses CoreGraphics which is not powerful enough to
allow an embedded SWT browser to fully function or render Flash videos. The
CALayer uses the CoreAnimation rendering model which obviously is capable.

There are some interesting notes in the latest Java Developer Preview
(10M3321+9M3321) regarding this issue and enabling the CALayer:

"The Java out-of-process applet plugin now uses the CoreAnimation rendering
model in browsers which support it. This now enables 3D technologies like
JOGL and LWJGL to embed their content in applets while running in Plugin2,
once they adopt the new JAWT API described below. 3D technologies need to
use a CAOpenGLLayer subclass to embed 3D content into the applet component
hierarchy.
If the browser does not support CoreAnimation rendering, CoreGraphics
rendering will be used, which cannot support sub-hosting 3D technologies."

One can read the full release notes by logging in to the Apple Member Center:
http://connect.apple.com

From the notes, it is hard to tell if enabling the CALayer for plugin2 is a Safari/WebKit
fix or is this going to be possible from SWT.

Dermot

----- Original Message ----- From: "Scott Kovatch" <skovatch.swt@xxxxxxxxx>
To: "Eclipse Platform SWT component developers list."
<platform-swt-dev@xxxxxxxxxxx>
Sent: Friday, February 18, 2011 2:18 PM
Subject: Re: [platform-swt-dev] SWT browser



On Feb 18, 2011, at 9:29 AM, Dermot Doherty wrote:

Applet performance is sluggish, which is not a SWT issue. Quick
explanation: To get applets and other heavy weight components to blend
better and integrate/overlap light-weight component in the surrounding
web-page, Apple changed the way that plugins are drawn. Java Plugin2 on
Mac now forces all rendering to an offscreen buffer and then draws it
through the CoreGraphics api, which is a great idea actually, but affects
the performance of the applet. It causes an unacceptable delay when
scrolling in an applet and a slight delay when typing in an applet. From
what I am reading it also breaks the frame rate on OpenGL Applets (JOGL &
LWJGL) - http://lwjgl.org/forum/index.php?topic=3341.0. Also, mouse over
events are not delivered to the applet.... clicks are.

The mouse event problem may be related to a bug I fixed recently.  See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337499 ... Plugin2 reparents
the applet into a new window and we weren't re-registering with the new
window for events.

And diverting a bit off topic here.... the new drawing architecture likely
explains another problem I was looking at with Chris Deckers. If you try
to display a page with Flash content (Flash 10.1 or later) in the Browser
widget inside an applet the Flash content only draws when the applet is
dragged out of the web page. This is because Flash is using CALayers for
its drawing. I haven't found a way to compensate for this in SWT, or see
if there even is a way to do it.

Recent Mac Java builds will let you obtain a CALayer instead of an NSView,
which is how we normally parent the embedded shell.  Using that to back
the NSView might be a possible solution.

-- Scott K.

------------------
Scott Kovatch
Pleasanton, CA



_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-swt-dev



Back to the top