wckdspn
Topic Author
Posts: 67
Joined: 18 Aug 2012, 23:14

Drag/input performance

01 Jan 2014, 21:43

So I am currently in the midst of implementing floating, dockable windows, and I've noticed quite a bit of lag dragging the window around. All I'm doing is resetting the TranslateTransform to the position of the mouse on mouse move. If it were simply framerate, I would expect it to be jerky, but it's animating smoothly... it's just way behind, almost as though it was trying to interpolate (I stop moving and release the button, but the window still catches up a few frames later).

I notice other controls which have dragging behavior (like scroll bars) exhibit similar behavior, though it seems a bit less noticeable. Do you have any idea what the root of it might be? Is there any means of altering the behavior, or is it unavoidable?
 
User avatar
jsantos
Site Admin
Posts: 2904
Joined: 20 Jan 2012, 17:18
Contact:

Re: Drag/input performance

03 Jan 2014, 11:15

I think that what you are observing is lag due to our multithreaded architecture. When you set the the position of an element in the main thread the following things happens:
  • The changes are sent in a job to the update thread. This job evaluates all the changes that were made in the last frame and update the visual representations. This implies tessellation, geometry buffers update, etc. When this job is finished the output is sent to the render thread
  • The render thread sent the graphic commands to the GPU (using DirectX, OpenGL, what ever)
  • These commands are executed by the GPU in its own thread, inside the driver.
The architecture is done that way to minimize the number of cycles that are stolen from the main thread of the game. But, as you can see, this deep pipeline implies that your changes done in the main thread can take several frames before they appear in the screen. This is more noticeable when you are attaching GUI items to non-gui items,for example, when attaching a panel to a 3D model, or when attaching a float panel to the cursor.

The solution is not clear and it varies from different platforms. Are you observing this in XamlPlayer or in your own application? If you are in your own native application you could disable multithreading by doing Update/WaitForUpdate/Render without parallelism.

Could you test this?
 
wckdspn
Topic Author
Posts: 67
Joined: 18 Aug 2012, 23:14

Re: Drag/input performance

03 Jan 2014, 18:32

In this particular case, I am in Unity.
 
User avatar
jsantos
Site Admin
Posts: 2904
Joined: 20 Jan 2012, 17:18
Contact:

Re: Drag/input performance

04 Jan 2014, 16:46

Ok, could you please file a bug with a sample scene? I think we need to investigate this issue to see is there is something we can do to improve it. There is a similar problem in the Primitives sample when a label is attached to a game object. It is in our internal list finding time to investigate it.

Thanks!
 
wckdspn
Topic Author
Posts: 67
Joined: 18 Aug 2012, 23:14

Re: Drag/input performance

06 Jan 2014, 03:51

Done.

In the meanwhile, I'm going to see about working around the issue by utilizing render textures onto quads. It's not ideal, given the number of additional draw calls it will create, but it will work for now.

As for UI on game objects (which I will soon be testing as well), I think I might use render textures as well, but create a large one with all of the scene controls I need, and simply map them dynamically. Since in my case the controls will all be in a fixed size, this might be practical. We'll see how it goes. My vacation ends today, so I'll be back to work tomorrow. Will try next weekend.
 
User avatar
jsantos
Site Admin
Posts: 2904
Joined: 20 Jan 2012, 17:18
Contact:

Re: Drag/input performance

07 Jan 2014, 15:16

We tested your scene today. We are observing a lag of two frames. This is definitely a bug in our side that needs to be solved. Thanks for the report!
 
wckdspn
Topic Author
Posts: 67
Joined: 18 Aug 2012, 23:14

Re: Drag/input performance

07 Jan 2014, 19:17

Thanks for taking a look. That's why I like you guys!

Quick question, have you guys internally attempted the rendering multiple controls to texture (attached to some off scene camera) then splitting them amongst separate scene quads in order to improve performance (over the one-render-texture-per-quad default setup). Just want to know if it's worth pursuing in case you guys tried it and it didn't exert much benefit.
 
User avatar
jsantos
Site Admin
Posts: 2904
Joined: 20 Jan 2012, 17:18
Contact:

Re: Drag/input performance

07 Jan 2014, 19:43

How many render to textures are you trying to optimize?
 
wckdspn
Topic Author
Posts: 67
Joined: 18 Aug 2012, 23:14

Re: Drag/input performance

07 Jan 2014, 20:04

Potentially a large number (~50 though it's variable) of small controls (floating character status info) that are all equal size.
 
User avatar
jsantos
Site Admin
Posts: 2904
Joined: 20 Jan 2012, 17:18
Contact:

Re: Drag/input performance

07 Jan 2014, 20:21

50 is a lot. Definitely trying to reuse a single render target should help performance. Although I am not sure if I would dedicate time to it because at the end, when we fix the lag issue, you will render directly to screen without render texture, won't you?

Who is online

Users browsing this forum: Google [Bot] and 1 guest