On 8/6/13 Aug 6, 10:07 AM, Scott Palmer wrote:
On 2013-08-06, at 9:10 AM, Artem Ananiev wrote:
On 8/5/2013 10:26 PM, Richard Bair wrote:
In this proposal, we also would be putting the next pulse on the end
of the queue, so it is impossible to starve input events.
Putting the next pulse on t
On 8/6/2013 6:07 PM, Scott Palmer wrote:
On 2013-08-06, at 9:10 AM, Artem Ananiev wrote:
On 8/5/2013 10:26 PM, Richard Bair wrote:
In this proposal, we also would be putting the next pulse on the
end of the queue, so it is impossible to starve input events.
Putting the next pulse on the
On 2013-08-06, at 9:10 AM, Artem Ananiev wrote:
>
> On 8/5/2013 10:26 PM, Richard Bair wrote:
>>
>> In this proposal, we also would be putting the next pulse on the end
>> of the queue, so it is impossible to starve input events.
>
> Putting the next pulse on the end of the queue is surprisi
On 8/5/2013 9:09 PM, Richard Bair wrote:
In the past we have seen situations where there are so many tasks
on the user event thread, that user response (even on desktop) was
not acceptable. Some of these items are getting better as we
improve design (ie less redundant layout operations causes by
On 8/5/2013 10:26 PM, Richard Bair wrote:
In the past we have seen situations where there are so many
tasks on the user event thread, that user response (even on
desktop) was not acceptable. Some of these items are getting
better as we improve design (ie less redundant layout
operations causes b
On 5/08/2013 20:46, Richard Bair wrote:
As I wrote in the previous email, it seems that we currently are not blocked waiting for
vsync(), at least on Windows with D3D pipeline. Anyway, even if we "fix" that,
what you propose is that sometimes both threads will be blocked (the render thread
wai
>> As I wrote in the previous email, it seems that we currently are not blocked
>> waiting for vsync(), at least on Windows with D3D pipeline. Anyway, even if
>> we "fix" that, what you propose is that sometimes both threads will be
>> blocked (the render thread waiting for vsync, the event thre
> I now see the picture.
>
> As I wrote in the previous email, it seems that we currently are not blocked
> waiting for vsync(), at least on Windows with D3D pipeline. Anyway, even if
> we "fix" that, what you propose is that sometimes both threads will be
> blocked (the render thread waiting f
> Right, I guess I don't have a complete picture of the threading model.
>
> I assume that user events like mouse clicks and key presses are coming in
> from some OS thread and queued on the "user event thread". Meanwhile things
> like runLater() are also queued on the user event thread. If oth
>>> In the past we have seen situations where there are so many tasks on the
>>> user event thread, that user response (even on desktop) was not acceptable.
>>> Some of these items are getting better as we improve design (ie less
>>> redundant layout operations causes by a single change/event).
On 8/5/13 Aug 5, 1:40 PM, Scott Palmer wrote:
On 2013-08-05, at 12:49 PM, David Hill wrote:
On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote:
The idea of user event starvation has been mentioned before and has me a little
confused… Why aren't things handled as a simple queue, with no prioritie
On 8/5/13 Aug 5, 1:09 PM, Richard Bair wrote:
In the past we have seen situations where there are so many tasks on the user
event thread, that user response (even on desktop) was not acceptable. Some of
these items are getting better as we improve design (ie less redundant layout
operations ca
On 2013-08-05, at 12:49 PM, David Hill wrote:
> On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote:
>> The idea of user event starvation has been mentioned before and has me a
>> little confused… Why aren't things handled as a simple queue, with no
>> priorities or anything, so starvation is impos
> In the past we have seen situations where there are so many tasks on the user
> event thread, that user response (even on desktop) was not acceptable. Some
> of these items are getting better as we improve design (ie less redundant
> layout operations causes by a single change/event).
Right,
On 8/5/13 Aug 5, 12:27 PM, Scott Palmer wrote:
The idea of user event starvation has been mentioned before and has me a little
confused… Why aren't things handled as a simple queue, with no priorities or
anything, so starvation is impossible? Is this something the OS is doing?
There is a "s
> The idea of user event starvation has been mentioned before and has me a
> little confused… Why aren't things handled as a simple queue, with no
> priorities or anything, so starvation is impossible? Is this something the
> OS is doing?
That's what I'm wondering too.
> In terms of renderin
The idea of user event starvation has been mentioned before and has me a little
confused… Why aren't things handled as a simple queue, with no priorities or
anything, so starvation is impossible? Is this something the OS is doing?
In terms of rendering fast enough that you can fit things into
On 8/1/13 Aug 1, 3:52 PM, Richard Bair wrote:
as far as I can read it, your idea is to start preparing the next frame right
after synchronization (scenegraph to render tree) is completed for the previous
frame. Do I get it correctly? If yes, we'll likely re-introduce the old problem
with input
On 8/1/2013 11:52 PM, Richard Bair wrote:
as far as I can read it, your idea is to start preparing the next
frame right after synchronization (scenegraph to render tree) is
completed for the previous frame. Do I get it correctly? If yes,
we'll likely re-introduce the old problem with input event
> as far as I can read it, your idea is to start preparing the next frame right
> after synchronization (scenegraph to render tree) is completed for the
> previous frame. Do I get it correctly? If yes, we'll likely re-introduce the
> old problem with input events starvation. There will be no or
Hi, Richard,
as far as I can read it, your idea is to start preparing the next frame
right after synchronization (scenegraph to render tree) is completed for
the previous frame. Do I get it correctly? If yes, we'll likely
re-introduce the old problem with input events starvation. There will be
On 7/26/13 Jul 26, 1:22 AM, Richard Bair wrote:
As for multiple scenes, I'm actually curious how this happens today. If I have
2 scenes, and we have just a single render thread servicing both, then when I
go to present, it blocks? Or is there a non-blocking present method that we use
instead?
Hi,
I'm probably missing something obvious and you guys on Glass / Prism / Quantum
can help set me straight. I was thinking tonight of a different way of
initiating pulse events that would, I think, completely smooth out the pulses
such that we don't end up with "drift" due to the timer being a
23 matches
Mail list logo
