[GEM-dev] single buffering

[Daniel Heckenberg]

Hi Ben,

I think the answer to your troubles - in both the short and long terms,
might be using double buffering but disabling the clearing of the frame
buffer at each page flip.  This is supported in Gem CVS.  This works well on
the hardware I've tested on, but screen appearance may vary depending on the
buffer flipping scheme being used - in fact I fear that on some hardware
you'll end up with nasty frame strobing as a different set of objects will
appear in each of the two frame buffers. The upshot is that you shouldn't
get any tearing.   Please let me know how you fare.

Here is the doco for this (ie some messages I posted to pd-dev some time
ago... sorry!)

Daniel said:
> - I'm going to implement some control over window clearing into gemwin.
> This can be used to do multipass rendering and various other things.  I'm
> proposing a couple of changes:
> - "clearmode f" message to [gemwin] to set which buffers are cleared
> automatically in each render cycle
> - [clear] object to be inserted into the rendering chain to force a clear
at
> that time.

A first pass at this is now in CVS.

The "clearmask N" message can be passed to a gemwin to set the clearing
behaviour.  "N" is simply cached and passed directly in the glClear call -
generate it using the GLdefine mechanism and  GL_COLOR_BUFFER_BIT,
GL_DEPTH_BUFFER_BIT etc..

[GEMglClear] can be used in other gemlists to control buffer clearing.

Daniel




----- Original Message ----- 
From: <ben at ekran.org>
To: <tigital at mac.com>
Cc: <cgc at humboldtblvd.com>; <ben at ekran.org>; <GEM-dev at iem.at>
Sent: Saturday, September 13, 2003 1:55 AM
Subject: Re: [GEM-dev] single buffering


> Hello All,
>
> After playing with my Gem GOPs today (released soon I hope! I wanted to
> get a few more done though) I'm even more assured that single-buffering is
> an important feature. Important enough for it to end up in all my patches
> in some form or another. The reason why? single buffering makes very very
> beutiful organic shapes possible with very little polys. They render
> really fast, and are incredably smooth. Today I was playing with a static
> object in single buffering playing a video on it. The effect was visually
> very close to pix_biquad and pix_blur (smoother than pix_blur) without any
> extra computation. The frames smoothly get blended together as if the
> frames were actually being cross-fade. I was blown away, and realize I
> really have to try it with live video!
>
> single buffering is, for me, one of the most important features, because
> it makes possible forms in time that would take a lot more processing
> power to do without it.
>
> Anyhow I am the only one to use single buffering??
>
> Ben
>
>
> > On Thursday, September 11, 2003, at 04:49  PM, cgc at humboldtblvd.com
> > wrote:
> >
> >> Quoting ben at ekran.org:
> >>
> >>> heya all,
> >>>
> >>> I was just tinkering with an old patch and I can't get
> >>> single-buffering
> >>> to
> >>> work. It worked before...
> >>>
> >>> I'm using Chris's bianry release for OSX from two weeks ago.
> >>>
> >>> The window does not complain, seems to enter single-buffering mode.
> >>> but
> >>> when I try and draw something (by banging on a gemhead) I get nothing
> >>> but
> >>> black. Changing the gemwin color does not render either, all black...
> >>>
> >>> Anyhow I hope it gets fixed as its something I often use.
> >>>
> >>
> >> There is no single buffering of GL contexts in OSX.  Never has been
> >> and never
> >> will be.  There's nothing we can do about this - it was a very early
> >> Apple
> >> design decision.
> >
> > ...uh, strictly speaking you're right, but I do remember a 'single
> > buffer' mode working in earlier versions of the GEM OSX port...I think
> > it was one of ben's early example patches:  but as I recall, ya had to
> > select single buffer before creating the window, which resulted in the
> > buffer getting filled by all drawing events, which was cool as long as
> > ya had a way to change your drawing colors/shapes/etc...I haven't tried
> > this in awhile, so I'll look into it tonight...
> >
> > l8r,
> > jamie
>
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>
>