Hi,

I would like to know if there is a clever way to use [gemframebuffer] with single buffering mode in gem.

What I would like to achieve is to be able to export a HD picture in single buffering mode using the Gem/examples/02.advanced/09.SnapshotSaveHD.pd exemple from jack . here is the slightly modified patch with the problem if somebody got any idea would be nice

SnapshotHD_SingleBuffering.zip

Cheers

@60htz It is because in single buffer mode you need to bang the gemheads for Gem to draw.
This will do it............ this.zip
I have included a hack....... that when the snap is taken it stops the play.... otherwise Pd crashes as the file is saved on my system. With the hack the error can be seen in the terminal....... but I am not sure what it means yet, The Play can then be re-started without a crash.
It might not crash for you with your directory structure?
The snap happens at the moment "save" is entered in the savepanel window (you will see it frozen in the Gem window as you press save)...... and the file is actually saved as play is started again.....??!
It could actually be saving the next frame, or it needs a bang to the object, and gets it from the gemstate as play is started again......?
If you cannot find the actual error "ERROR: -50 in GraphicsExportSetOutputFile()" then you could just automate the re-start of play, maybe after a short delay?
David.

Thanks @whale-av!

And sorry, I think I didn't explained my problem correctly in my first post..

Actually exporting works in single buffering. But what I would like is being able to draw multiple shape and not cleaning the screen between drawing, like in a blackboard, then export the result. Here is an example, as you can see the exported picture have only one dot

SnapshotHD_SingleBuffering2.zip

@60htz Well, that crashes my system.
So I cannot test, but this might work on your system...... that.zip
It should.
It seems to be quicktime that crashes windows as the file is saved.
It does write the buffer though.
Using pix_write it does not crash, but doesn't save high res either.
Banging the [gemhead 99] which is collecting the circles, writes over the window with a new black square in your example....... maybe a clue?...... the screen is not actually cleared I think.
David.

@whale-av Thanks this is working with both solutions on my system. I don't know about the black square pb, on my system the file looks correct but the buffer resolution is stuck to 512x512, (the dimension of the gemwin buffer) even if the pix_snap object is set to 4000x4000... I tried to put a pix_info and I have got -1 for width and height strange.

check the pict here:

exported_picts.zip

@60htz Here I have bumped the Gem window up to 1000 pixels square with the dimen message.
[pix_write] then prints correctly when set the same.
I think you will be limited by the GFX Card max resolution........ but it is strange that you were not when printing the [gemhead] gemlist.
I think that although the gemlist is the size of the Gem window (multiplied by its channels rgba) the [pix_buffer] must be filled to it's defined capacity...... so the window is re-sampled?
Looking at a zoom of the teapots I saved at 4000 x 4000 they are not really HD...... so nothing fancy..... just stretched.
Something to chew on.
David.

@whale-av, I can also make a correct 4000x4000pixel pict if I change the size of the [gemwin] accordingly so I don't think it's a GFX card issue here.

When I go trough [gemframebuffer], wich enable to make an offscreen rendering without displaying in a such size, what I have got is only a single dot in correct 4000x4000px.
SO I guess the problem is [gemframebuffer] and single buffering uncompatibility.

here is the proof that gemframebuffer clear everyframe even if single buffering is on:
framebuffer_single_cleared.pd