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
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
On 8/6/2013 6:07 PM, Scott Palmer wrote:
On 2013-08-06, at 9:10 AM, Artem Ananiev artem.anan...@oracle.com 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.
On 8/6/13 Aug 6, 10:07 AM, Scott Palmer wrote:
On 2013-08-06, at 9:10 AM, Artem Ananiev artem.anan...@oracle.com 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.
On 2013-08-05, at 12:49 PM, David Hill david.h...@oracle.com 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
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
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, but
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 other
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 for
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
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
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
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
13 matches
Mail list logo
