RenderDocument, mozAfterPaint, offscreen Window and slow rendering




Layout: View Rendering
6 years ago
a day ago


(Reporter: joffrey.romero, Unassigned)


Windows 7

Firefox Tracking Flags

(Not tracked)




6 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120420 Firefox/14.0a1
Build ID: 20120420030653

Steps to reproduce:


XULRUNNER APPLICATION, last mozilla-central nightly, in a C++ XPCOM Component on msWindows MSVC10.

I'm working on a wrapper for Mozilla Gecko that allows a developper to manage multiple 'browsers' and render their contents to a texture for ogre3D.

Actual results:

I am rendering via RenderDocument (nsIDOMWindowUtils) and MozAfterPaint event.

There is a strange problem : I'm working with browsers in hidden windows...

When the window is hidden or offscreen, the application is slow for create rendering texture.
When Browsers windows are showed and visible in monitor screen, that's work fine and this is really fast.

What do you think about that ?
Can you quantify "slow"?

Generally, I believe RenderDocument will reuse existing rasterized layers if they already exist.  So in cases when the document has been painted before, it can definitely be somewhat faster than when the document hasn't been painted before. But are you seeing RenderDocument() take longer than a pain normally takes?
Component: XPCOM → Layout: View Rendering
QA Contact: xpcom → layout.view-rendering

Comment 2

6 years ago

Okay thank you for the answer :)

Later, I will test the working time of RenderDocument function.
But for now, I think the event mozAfterPaint is delayed.

Is there a way to force layer to be painted ?

Comment 3

6 years ago
I did some tests and I realized that the RenderDocument function worked well.
In case of invisible window (or offscreen), the mozAfterPaint event is delayed.
I don't know why...

Comment 4

a day ago
Per policy at If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Last Resolved: a day ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.