On Mon, Jan 16, 2012 at 1:29 PM, Cyrille Henry ch@chnry.net wrote:
Le 16/01/2012 13:23, rolf meesters a écrit :
On Sun, Jan 15, 2012 at 10:47 PM, Cyrille Henry <ch@chnry.net mailto: ch@chnry.net> wrote:
Le 15/01/2012 18:13, rolf meesters a écrit :
it's at the max of 64 Mb.do you have 16 pix_image? if you load 16 time the same image, you need 16 time more memory than necessary.
then, you could use a single gemhead / pix_image / pix_texture to load the image and share the texture Id. then using gemhead/pix_texture(to load the texture Id)/pix_coordinate on your abstraction.
also, you can only resize the image in order to fit in the available GPU memory.
anyway, pd/GEM should not exit without warning. pd bug report should be made.
Cyrille
i have 16 pieces, which are parts of 1 big picture; like with a puzzle they have to be displayed at their specific coordinates. there's no pix_image involved. (the abstraction is attached)
ah, ok. you're using a pix_buffer. good, the image is not loaded many time.
so the only solution i can imagine is to resize the image in order to use less memory.
c
a bit of progress:
for the intel815 (which i have on the PIII) it is possible to set a value for VideoRam in xorg.conf. i made it 16384 kb: now Pd/GEM does not quit. the patch goes through the motions, there's a GEM-window, but only a white rectangle where a picture should be.
GEM tells me that direct rendering is enabled, but still only 8 clor bits.
and now every time at a change in the rendering: GL: invalid operation
r
rolf btw thanks for reacting