nanogui: Thread: Are we allowed to mandate GrFlush()?

I'm looking at what amounts to a double- or triple-buffered display
system
where the simplest scheme to handle what I want to do is to mandate the
user to 'flush' from his primary output buffer to a display buffer.  I'm
thinking
of trying to do this by making GrFlush not just a good idea but in fact
mandatory after a set of draw operations when the user is ready to
display
to the screen, but I'm wondering if this is really legitimate, or
whether too
many programs assume that what they draw will automatically be displayed

and don't bother calling GrFlush().

Steven Stadnicki
####@####.####

Most programs that don't care about buffering just draw to the screen, and 
simply assume that the screen will be drawn in due time.  And programs that 
do care about buffering are usually writing to their own offscreen buffers 
anyway, and do a blit when they are ready to refresh the screen.  

In any case, a GrFlush would be probably unnessesary, as a simple program 
wouldn't really care if there are a few microseconds between drawing 
operations, and the buffered programs would have already taken it all into 
consideration.

Jordan

On Tuesday 07 August 2001 09:06, Steven Stadnicki mentioned:
> I'm looking at what amounts to a double- or triple-buffered display
> system
> where the simplest scheme to handle what I want to do is to mandate the
> user to 'flush' from his primary output buffer to a display buffer.  I'm
> thinking
> of trying to do this by making GrFlush not just a good idea but in fact
> mandatory after a set of draw operations when the user is ready to
> display
> to the screen, but I'm wondering if this is really legitimate, or
> whether too
> many programs assume that what they draw will automatically be displayed
>
> and don't bother calling GrFlush().
>
> Steven Stadnicki
> ####@####.####
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Jordan Crouse wrote:

> In any case, a GrFlush would be probably unnessesary, as a simple program
> wouldn't really care if there are a few microseconds between drawing
> operations, and the buffered programs would have already taken it all into
> consideration.

Well, if it were only a few microseconds then I would agree; the problem is
that
the copy operation from the draw buffer to the screen buffer is a little more
involved
than just a copy (I can't really get into the details, unfortunately, for IP
reasons)
and whenever it's called it may take many milliseconds to do -- so I really
don't
want to invoke it on every graphics operation, which is why I want to do it
during
the GrFlush() call, if I'm allowed to demand that the user make that call.

Steven Stadnicki
####@####.####

> On Tuesday 07 August 2001 09:06, Steven Stadnicki mentioned:
> > I'm looking at what amounts to a double- or triple-buffered display
> > system
> > where the simplest scheme to handle what I want to do is to mandate the
> > user to 'flush' from his primary output buffer to a display buffer.  I'm
> > thinking
> > of trying to do this by making GrFlush not just a good idea but in fact
> > mandatory after a set of draw operations when the user is ready to
> > display
> > to the screen, but I'm wondering if this is really legitimate, or
> > whether too
> > many programs assume that what they draw will automatically be displayed
> >
> > and don't bother calling GrFlush().
> >
> > Steven Stadnicki
> > ####@####.####
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ####@####.####
> > For additional commands, e-mail: ####@####.####

: > In any case, a GrFlush would be probably unnessesary, as a simple program
: > wouldn't really care if there are a few microseconds between drawing
: > operations, and the buffered programs would have already taken it all into
: > consideration.
: 
: Well, if it were only a few microseconds then I would agree; the problem is
: that
: the copy operation from the draw buffer to the screen buffer is a little more
: involved
: than just a copy (I can't really get into the details, unfortunately, for IP
: reasons)
: and whenever it's called it may take many milliseconds to do -- so I really
: don't
: want to invoke it on every graphics operation, which is why I want to do it
: during
: the GrFlush() call, if I'm allowed to demand that the user make that call.

First, GrFlush() doesn't cause the draw buffer to be copied to the
screen buffer.  Instead, it writes a few bytes from the client down
the pipe to the server, which are then interpreted, which then
result in possible drawing/clipping.  Second, this client-side command
buffer is flushed automatically whenever the user executes a GrXXX
call that requires a return value, that is, when any GrXXX non-void
function is called.  Finally, GrFlush is called whenever GrGetNextEvent
is called, which in most programs is after every draw operation.

So GrFlush isn't necessary, whether mandated or not.

Regards,

Greg