On Mon, Jan 16, 2012 at 1:29 PM, Cyrille Henry <c...@chnry.net> wrote:
> > > Le 16/01/2012 13:23, rolf meesters a écrit : > > >> >> On Sun, Jan 15, 2012 at 10:47 PM, Cyrille Henry <c...@chnry.net <mailto: >> c...@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 >> >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list