----- Original Message ----- > From: "Robert O'Callahan" <rob...@ocallahan.org> > To: "Jeff Muizelaar" <jmuizel...@mozilla.com> > Cc: dev-platform@lists.mozilla.org, "Vladimir Vukicevic" > <vladi...@mozilla.com>, avih...@yahoo.com, "Bas Schouten" > <bschou...@mozilla.com> > Sent: Tuesday, August 13, 2013 10:34:38 PM > Subject: Re: vsync proposal > > > A couple things that are not clear to me from this proposal: > > - when the vsync event is sent? > > > > Depends on the platform. I believe on Windows we can call DwmFlush on a > helper thread and fire it when that returns.
Calling DwmFlush is bad. Calling http://msdn.microsoft.com/en-us/library/windows/desktop/bb174559%28v=vs.85%29.aspx is better. > > - how does it deal with a blocking swapbuffers()? > > > > Blocking swapbuffers isn't really compatible with having multiple windows > on one compositor thread. If we want to move each window compositor to its > own thread and keep blocking on swapbuffers, then we'll have to revise this > proposal. Do we need to do that? I don't think we are ever forced to have a blocking SwapBuffers. All in all I have some concerns with the current plan. I believe the basics are solid, having a thread (or some other method) generate Vblank events is a good thing. I also believe using that to drive animations and some other things is a good idea. I think that should be decoupled from the Compositor though. I've discussed this a little on IRC and we've talked a little about this in the graphics meeting, one concern in particular I have with this idea is the idea that you have 'low latency' windows and 'high latency' windows, I think that's not true. Rather, I think there's drawing where the latency doesn't really matter, and drawing where it does. Here's some quick ideas I had about things (very rough around the edges still): First let's conclude we're not trying to do a vblank synchronized present, so we're not really vsyncing here (the preventing tearing discussion is completely separated as far as I can tell), we merely want to use the vblank signal to determine if a frame has been presented to the monitor. Take into account I have little idea of how the RefreshDriver currently works. Then what you basically have is two sorts of drawing: - Drawing related to user input (panning/zooming/etc), where ideally you need minimal latency - Drawing related to things we know in advance, video, animations, etc. Then there's requestAnimationFrame, which I guess is kind of special, I don't know enough about it to have a good idea when that should happen, I suppose vblank is as good a time as any? Since you want composition to occur whenever drawing has occurred, I don't really think it should really be what's working on doing any processing for the vblank event. The VBlank event should just fire, indiscriminately whenever VBlank occurs. I believe we should then consume that event on whatever thread is actually doing drawing which might want to know about this (a user input thread? the main thread?) and these should then decide when to do their drawing and if that warrants a new composition. That way you could have, just after vblank, all your scheduled drawing be done, and a composition scheduled. But then if right before the next vblank a panning/zooming event comes in you can still process that and present a new frame to minimize latency (if desired). What you could also do is do all your main thread drawing and processing rAF things just after vblank, since they'll likely be somewhat time consuming, and schedule your composition only for example 5 ms before VBlank (since that will likely be fast). You could then make some adjustments to the layer tree through the APZC for user input later in the frame, and still have those taken into account for composition, that would give you a minimal input latency without wasted work and still starting the content drawing required as early as possible giving it maximum opportunity to make the next frame. This may be a little bit too complicated for a first implementation, but I wanted to throw it out there as a suggestion as well. Bas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
