Hi Ben, hi list,
Anyhow I proposed a "clear" selector that could be changed without destroying and re-creating the gemwindow. (I hope) basically a nice feature for "trails" so that single-buffering is not depended upon for "not clearing"
so this boils down to still running GEM in double-buffered mode, but having to manually clear the window if the default behaviour (totally clearing the gemwin after each rendering cycle) has been changed, right? That would emulate the single buffered mode ... and once again, it would be a nice feature to have. I've been thinking about the possibility of implementing this feature on a per-geo-basis (best of both worlds) - but this is probably impossible to implement.
with kind regards, thoralf.
___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
Thoralf Schulze wrote:
Hi Ben, hi list,
Anyhow I proposed a "clear" selector that could be changed without destroying and re-creating the gemwindow. (I hope) basically a nice feature for "trails" so that single-buffering is not depended upon for "not clearing"
so this boils down to still running GEM in double-buffered mode, but having to manually clear the window if the default behaviour (totally clearing the gemwin after each rendering cycle) has been changed, right? That would emulate the single buffered mode ... and once again, it would be a nice feature to have.
actually this was exactly what i had in mind when i asked, whether anybody needs single-buffer mode apart from non-deletion mode.
if we do have some feedback that allows for either normal (doublebuffered) rendering AND rendering without clearing the last frame (singlebuffered) AND doing something in between (motion-blur), this would cover 80-90% of the single-buffer usage (i believe)
mf.a.sdr IOhannes
Hi Johannes,
if we do have some feedback that allows for either normal (doublebuffered) rendering AND rendering without clearing the last frame (singlebuffered) AND doing something in between (motion-blur), this would cover 80-90% of the single-buffer usage (i believe)
Yeah ... This would definitely be the "best of both worlds"-solution. I had the (obviously wrong) impression that you were about to axe single buffered mode without substitution.
with kind regards, Thoralf.
___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
Hi,
I agree that should cover the uses of single-buffering.
:)
B>
IOhannes m zmoelnig wrote:
Thoralf Schulze wrote:
Hi Ben, hi list,
Anyhow I proposed a "clear" selector that could be changed without destroying and re-creating the gemwindow. (I hope) basically a nice feature for "trails" so that single-buffering is not depended upon for "not clearing"
so this boils down to still running GEM in double-buffered mode, but having to manually clear the window if the default behaviour (totally clearing the gemwin after each rendering cycle) has been changed, right? That would emulate the single buffered mode ... and once again, it would be a nice feature to have.
actually this was exactly what i had in mind when i asked, whether anybody needs single-buffer mode apart from non-deletion mode.
if we do have some feedback that allows for either normal (doublebuffered) rendering AND rendering without clearing the last frame (singlebuffered) AND doing something in between (motion-blur), this would cover 80-90% of the single-buffer usage (i believe)
mf.a.sdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
-
B. Bogart -
IOhannes m zmoelnig -
Thoralf Schulze