RenderDocument, mozAfterPaint, offscreen Window and slow rendering

RESOLVED INACTIVE

Status

()

Core
Layout: View Rendering
RESOLVED INACTIVE
6 years ago
a day ago

People

(Reporter: joffrey.romero, Unassigned)

Tracking

Trunk
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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:

Hello,

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.
(See https://bugzilla.mozilla.org/show_bug.cgi?id=718985)


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
(Reporter)

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 ?
(Reporter)

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 https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a day ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.