Bug 94837 – [BlackBerry] Replace the three different rendering mechanisms for clearing the render queue

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit BlackBerry

[Adam Treat]

Currently, we have three different mechanisms for clearing the render queue. 
The first mechanism is render on idle.  Whenever the webkit thread becomes idle
(read: no more events in its queue) we render the next job in the render queue.
 This is the primary means we use for clearing the render queue.  However, this
mechanism has a flaw, it is such a low priority mechanism that sometimes the
queue grows so fast due to higher priority events adding rects to the queue
that this mechanism can't possibly keep up.  That is what leads to the second
mechanism: rendering right before a timer is fired when we discover that the
render queue is under pressure and rendering on idle can't keep up.  However,
there are still degenerate cases where even this mechanism does not allow us to
keep up.  That brings us to the third mechanism: rendering based on a timer
that is a catch-all.

The second and third mechanisms lead to very large render jobs as they try and
clear the queue faster when it comes under pressure.  These very large render
jobs end up keeping the webkit thread busy with a message that can take large
fractions of a second to resolve.

These three mechanisms were put in place when the backingstore had a different
overall design that was not truly asynchronous.  This patch replaces these
three mechanisms with a single one that uses the platform messaging classes to
full purpose - a uniquely coalescing message that has a higher priority level
than timers making sure the render queue can never come under pressure.

See: PR 197738 internally.

[Adam Treat]

Created attachment 160228 [details]
Fix

[WebKit Review Bot]

Comment on attachment 160228 [details]
Fix

Clearing flags on attachment: 160228

Committed r126485: <http://trac.webkit.org/changeset/126485>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.