[PD] buffer 1 with Gem

[B. Bogart]

Personally I only ever used it for "traces" that is manual control of
clearing the buffer before flip.

It would be handly to have a "clear 1|0" message to gemwin. Chris
Clepper was talking about some kind of alpha clearing of the buffer that
sounds nice, that is the buffer is cleared to a certain degree (fill
with a solid colour but only at a settable opacity. Using this you could
control how the old frames get fall-off the buffer (get occluded by
multiple iterations of transparent "clearing".

Maybe "clear 0" clears the screen as normal (the default)
"clear 1" clear the screen with 1% transparency "clear 100" clear with
100% transparency (no clearing).

The scale from 1-100 is very un-gem like, and its transparency, and not
opacity, which is confusing. I find new users to Gem get damn confused
when some messages "dimen" depend on the state of others "create" so
when its not nessesary it would be handy to keep this functionality in
one message.

The most gem-like way would be:

"clear 0" turns off clearing "clear 1" turns it on.
"clearalpha 0" clears 100% transparent (default). "clearalpha 1" clears
100% opaque. This is not so bad when I look at it. :)

Oh and I think buffer 1 on MacOS is what does not work. Other platforms
I think are fine. With the above added functionality we would not need
to remove it for buffer freaks, but those who want traces would no
longer use it.

B.

IOhannes m zmoelnig wrote:
> cyrille henry wrote:
>
>> hello,
>>
>> i've got somes problems : nothing is draw on the gemWindows in buffer 1
>> mode (gem debian installer and latest cvs, linux, pd 38.4)
>>
>> i can't find any example patch of the "buffer 1" feature in gem, so I
>> don't know where the problem comes from.
>
>
> you are sure you are banging the [gemhead]s ?
>
>>
>> does anyone have an example to share?
>
>
> 04.pix/10.PixDataSimple.pd ??
>
> i thought the "buffer 1" was broken somehow, but the example told me it
> works.
>
> btw, what do you people need the "buffer 1" feature for ?
> i thought of removing it a la long and "replace" it with some
> controllable feedback in double-buffered mode.
> (this means: if single-buffered mode is used only to not make "traces"
> of objects, this could be handled otherwise.)
> if someone needs full control over the render-chain, removing would
> probably be a bad idea.
>
>
> mfg.asd.r
> IOhannes
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20050606/e185cea0/attachment.pgp>