On Mon, Aug 13, 2012 at 6:51 AM, Benjamin Smedberg wrote:
> On 8/11/2012 8:14 AM, Robert O'Callahan wrote:
>
> I think making the HWND message loop thread not be the main thread would
> be very hard. Drag and drop and IME for example require synchronous
> processing.
>
> How does Chrome do this?
On 8/11/2012 8:14 AM, Robert O'Callahan wrote:
As a partial aside, I think it might be *better* if the OMTC
thread was the thread which actually processed windows events,
especially if we didn't ever need to block the OMTC thread on the
main gecko thread and merely dispatch them
On Sat, Aug 11, 2012 at 1:29 AM, Benjamin Smedberg wrote:
> On 8/9/2012 7:27 PM, Matt Woodrow wrote:
>
>> When OMTC arrives, which thread will be running the widget event loop
>>> and receiving WM_PAINT messages?
>>>
>> Still the main gecko thread, we just don't paint synchronously in
>> response
> As a partial aside, I think it might be *better* if the OMTC thread
> was the thread which actually processed windows events, especially
> if we didn't ever need to block the OMTC thread on the main gecko
> thread and merely dispatch them asynchronously: this could
> significantly improve our sit
On 8/9/2012 7:27 PM, Matt Woodrow wrote:
When OMTC arrives, which thread will be running the widget event loop
and receiving WM_PAINT messages?
Still the main gecko thread, we just don't paint synchronously in response to
this event. Apparently this is fine.
Do you have documentation on this? H
On 08/10/2012 02:59 PM, smaug wrote:
On 08/09/2012 08:36 PM, Boris Zbarsky wrote:
On 8/9/12 11:37 AM, Benjamin Smedberg wrote:
This seems important. If the computer is running close to 100% CPU which
is why paints are being throttled, then we're just introducing extra
work for no benefit. We kn
On 08/09/2012 08:36 PM, Boris Zbarsky wrote:
On 8/9/12 11:37 AM, Benjamin Smedberg wrote:
This seems important. If the computer is running close to 100% CPU which
is why paints are being throttled, then we're just introducing extra
work for no benefit. We know that a significant portion of our u
From: "Matt Woodrow"
To: dev-platform@lists.mozilla.org
Cc: "Robert O'Callahan"
Sent: Thursday, August 9, 2012 11:41:16 AM
Subject: Paint Timing Changes and Tp5
In preparation for relanding DLBI (display-list based invalidation - Bug
539356), I'm going to be landing
CC'ing dev-platform since I accidentally removed it.
- Forwarded Message -
From: "Matt Woodrow"
To: "Benjamin Smedberg"
Sent: Friday, August 10, 2012 11:27:20 AM
Subject: Re: Paint Timing Changes and Tp5
>When OMTC arrives, which thread will be running
On 8/9/12 11:37 AM, Benjamin Smedberg wrote:
This seems important. If the computer is running close to 100% CPU which
is why paints are being throttled, then we're just introducing extra
work for no benefit. We know that a significant portion of our user base
has relatively slow computers, and we
On 8/8/2012 9:16 PM, Matt Woodrow wrote:
Are there details on what this actually means? e.g. don't we *have* to
paint when when we receive a WM_PAINT event, and usually we shouldn't at
other times?
To clarify, these patches split painting up into two steps:
1) Compute invalid regions, build d
If you're running under Aero composition on Vista/W7 (and perhaps W8,
haven't tested there), Aero will sometimes decide to dispatch paint
events (and as a result, composite) less often in response to measured
GPU load and other characteristics. That might be responsible for what
you're seeing there
>Are there details on what this actually means? e.g. don't we *have* to
>paint when when we receive a WM_PAINT event, and usually we shouldn't at
>other times?
To clarify, these patches split painting up into two steps:
1) Compute invalid regions, build display lists, layers and repaint the c
On 8/8/2012 7:41 PM, Matt Woodrow wrote:
In preparation for relanding DLBI (display-list based invalidation - Bug
539356), I'm going to be landing a set of patches to change the timing of our
painting.
These move painting to be driven by the refresh driver, instead of the OS
widget's paint ev
On Thu, Aug 9, 2012 at 12:24 PM, Boris Zbarsky wrote:
> On 8/8/12 7:41 PM, Matt Woodrow wrote:
>
>> These move painting to be driven by the refresh driver
>>
> ...
>
> Unfortunately it appears that we were being artificially throttled to
>> below 60fps by the widget paint events
>>
>
> Shouldn't
On 8/8/12 7:41 PM, Matt Woodrow wrote:
These move painting to be driven by the refresh driver
...
Unfortunately it appears that we were being artificially throttled to below
60fps by the widget paint events
Shouldn't the refresh driver likewise throttle? Or is that not working
very well?
In preparation for relanding DLBI (display-list based invalidation - Bug
539356), I'm going to be landing a set of patches to change the timing of our
painting.
These move painting to be driven by the refresh driver, instead of the OS
widget's paint event. This is a required change for DLBI, an
17 matches
Mail list logo
