Re: [Chromium-dev] runaway rendering

[Keith W. <ke...@tu...>]

On Thu, 28 Mar 2002 07:55:38 -0800, Greg Humphreys wrote:

> > One thing I've noticed is the potential for large latencies
> > arising from the
> > way chromium decouples the application from the rendering back end, with
> > buffering in between.  The typical case is an application that emits small
> > (data-wise) but slow-to-render frames in a loop.  The Mesa gloss
> > demo works
> > for software rendering, the q3 menu screens are good examples of
> > this that can
> > trap hardware renderers fairly easily.
> 
> I thought the implementation of SwapBuffers in both the pack and tilesort
> SPU forces a flush.

As it stands I can buffer up several minutes worth of frames running apps like gears or gloss or isosurf in display-list mode against software mesa.  (using the pack spu)

> > Typically some sort of flush or synchronization is done on swapbuffers - I
> > haven't looked closely enough at what's possible in chromium to
> > implement such a synchronization.
> 
> The tilesort SPU has 'sync_on_swap', which waits for a ping from the servers
> before continuing.  If I understand what you're asking for, you'd like that
> ping to affect the *next* frame?

This is fine, I was just saying you don't have to be quite so strict - for most purposes it's ok to just limit the number of buffered frames to something small.

> I think this would be straightforward; just make a special Swap_writeback
> message that's different from the other writebacks, and wait for it at the
> beginning of tilesortspu_SwapBuffers on every frame except #1.

If there's already a mechanism in the tilesort spu, it's not worth revisiting for this.  But whatever's in the pack spu isn't working - I'll look more deeply.

Keith