447975 - Create Shared RenderDocument view component for fennec and for embedding

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, defect)

Description

[Oleg Romashin (:romaxa)]

Currently fennec browser is using special rendering view based on Canvas.drawWindow(shell->RenderDocument) API.

This rendering view implementation include such functionality as Events/Images/Scrolling layout updates synchronization....

I think it would be reasonable to move that functionality to separate shared component and expose some API which can be used by Fennec browser and other applications... for example embedding.

Probably it should some sort of new nsIView + nsIWidget implementation with some API which will allow to draw and synchronize layout to some drawable area (canvas/widget/....)..

Comment 1

[Stuart Parmenter]

Embedding targets should probably just load the xul from fennec, or perhaps we should look at splitting some of it out eventually, but it is too early to do that now.

Comment 2

[Oleg Romashin (:romaxa)]

(In reply to comment #1)
> Embedding targets should probably just load the xul from fennec,

Yep, that is possible, but my goal not only fennec view but always responsive fennec view (pannable and zoomable)...

But I think it is possible to do only with 2 different processes...
First process will have rendering/js engine and will provide ready images of layout and it updates...
Second process  - UI + static image (always pannable and zoomable).
+ Synchronization between that 2 processes:
UI events/scroll position from Second -> First process
Layout updates by images in shared memory from First to second process.

Comment 3

[Stuart Parmenter]

It is very possible to do with a single process.

Comment 4

[Stuart Parmenter]

We just need to tune some preferences and do some additional profiling and we'll be good to go.

Comment 5

[Oleg Romashin (:romaxa)]

(In reply to comment #4)
> We just need to tune some preferences 
Is that preferences already exists?

> and do some additional profiling and
What you mean? Javascript, images decoding, layout reflow, gfx rendering, plugins load.... All these things can affect on UI responsiveness...

Do you think it is really possible to fix all of them in meaningful time? or I just don't understand some magic and obvious solution....

> we'll be good to go.
> 

Comment 6

[Stuart Parmenter]

(In reply to comment #5)
> (In reply to comment #4)
> > We just need to tune some preferences 
> Is that preferences already exists?
> 
> > and do some additional profiling and
> What you mean? Javascript, images decoding, layout reflow, gfx rendering,
> plugins load.... All these things can affect on UI responsiveness...
> 
> Do you think it is really possible to fix all of them in meaningful time? or I
> just don't understand some magic and obvious solution....
> 
There is no magic bullet.

There are certainly many factors that will effect responsiveness.  The areas you mention (Javascript, images decoding, layout reflow, gfx rendering, etc) have people looking at them currently for the mobile context, so we should start seeing improvements.  Other factors, such as network delays and load times will effect how quickly we can get the right data on the screen.  Pat McManus is looking at the network effects (see his various newsgroup posts).  Preferences such as 
nglayout.initialpaint.delay, content.notify.interval, may help, but need to be carefully studied to find the optimal values (and they may change as we optimize other areas of the code).

I think it would be a much better use of your time helping optimize these areas areas than it would to spend time trying to design a work-around using 2 process.

Comment 7

[Benjamin Smedberg]

Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.