Thanks. I have added a comment to that bug report.

I note somewhere else on the list suggested using a kind of 'whiteout' approach by moving a white canvas over the the offending items prior to resizing - after resizing the canvas 'looks' ok. In short, visually this solves the issue, but if you do this overlapping other objects / GOPs etc then they suffer from the rendering issue by getting whited out.

That's part of the workaround.

To resolve the issue completely (at least visually) I have a receive object in each GOP abstraction which acts as a global message bus to all GOPs. This bus is connected to a namecanvas send and sends a vis 0 and vis 1 message to turn the (and each and every) GOP's visibility on/off.

There is probably a more elegant solution .. which I'll post when/if I figure it.

Best

On 06/07/2011, at 12:22 PM, Hans-Christoph Steiner wrote:

Hey Christian

Thanks for the thorough bug report, the video is great. I think that's a known bug, or at least it seems familiar to me. It would be great to have this info in the bug tracker so we can keep track of it. This bug seems similar:

https://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=55...

If that's not it, then feel free to create a new bug report in the tracker.

.hc

On Jun 28, 2011, at 10:51 PM, Christian Haines wrote:

...

Hi All

I have created an GOP abstraction which I include in a parent parent. The GOP interface has a button that resizes it by sending a 'coords' message to the GOP abstraction canvas (namecanvas named). When it resizes larger it renders the larger interface properly over the patch's white background. However, when it resizes smaller it leaves a remnant of the larger interface visible. Sometimes to correctly show the smaller interface, I have to redraw / refresh the window by moving the window - this doesn't always work though. In fact it only works when the parent patch has a '#coords' line with a specific configuration in it - of which I'm not sure. I'm on OSX. I've seen the issue documented elsewhere but never read a full description on how to resolve it fully.

See the issue here: http://echoblue.com.au/pd/goprenderissue.mov

At the moment I am sending a message back to the parent patch from the GOP abstraction to change the parent patch's 'setbounds' by 1 pixel and then move it back - this resolves that issue but, as mentioned, not consistently. Regardless, it creates two more issues: (1) setbounds behaves oddly - doesn't resize until a close and reopen; and/or moves the objects in the patch window without resizing; (2) I can't know the patch window size dynamically (say by querying the canvas) hence any size change by setbounds is not necessarily the same as the original window size (if it was resizing!).

Any suggestions would be greatly appreciated

-- Christian

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom

-- Christian Haines

Lecturer / Co-Director Electronic Music Unit

Elder Conservatorium of Music University of Adelaide South Australia 5005

Ph: +61 8 8303 3799 Fax: +61 8 8303 4423 Email: christian.haines@adelaide.edu.au Web: http://emu.adelaide.edu.au http://music.adelaide.edu.au Study: http://emu.adelaide.edu.au/study/ Location: Schulz Building, Level 5 , 5.13

CRICOS Provider Number 00123M

This email message is intended only for the addressee(s) and contains information that may be confidential and/or copyright. If you are not the intended recipient please notify the sender by reply email and immediately delete this email. Use, disclosure or reproduction of this email by anyone other than the intended recipient(s) is strictly prohibited. No representation is made that this email or any attachments are free of viruses. Virus scanning is recommended and is the responsibility of the recipient.

On Thu, 2011-07-07 at 08:47 +0200, Ivica Ico Bukvic wrote:

Neither if those are fixes but rather hacks that should be avoided because once the bug is fixed you will have to go back and change all your existing patches with this workaround. Pd already redraws entire gop object every time you move it or change its properties. I think this is because of out-of-order redrawing bug that persists in pd (at least it did since last time I checked). If you can please send a simplified version of the actual patch to test it in the l2ork iteration of pd which has afaik all known gop issues fixed, that could shed some light where the problem lies.

I just had a quick look into this issue and it appears that pd-l2ork is affected as well mainly since coords function was never designed to be called independently (e.g. via live scripting) as this function is incomplete in and of itself when it comes to redrawing the object in question (namely, it does not redraw the object and applies new xy/margins before calling the redrawing function so that the redrawing function never sees objects that fall outside the newfound rectangle as being visible in the first place). I think this is a fundamental problem with runaway things some users are trying to explore that were never meant to do what they expect them to. There should be a separate external API for scripting purposes that ensures that things are done in the right order/way. As it stands right now there is a "fix" (sort of) that will make current pd usable with the said coords scripting command if the following patch is applied to the g_canvas.c. The downside is that there is yet another redundant redraw of the gop-ed object, which is not very efficient at all. And while this is not likely to cause audio dropouts but be aware that this is not something that pd was meant to do necessarily interactively.

NB: You may have to apply this diff with some level of fuzz since it is designed to apply cleanly against pd-l2ork trunk rather than pd-extended. That said, this part of the code should be identical (AFAIK).

Cheers!

Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

Christian Haines christian.haines@adelaide.edu.au wrote: Thanks. I have added a comment to that bug report.

    I note somewhere else on the list suggested using a kind of
    'whiteout' approach by moving a white canvas over the the
    offending items prior to resizing - after resizing the canvas
    'looks' ok. In short, visually this solves the issue, but if
    you do this overlapping other objects / GOPs etc then they
    suffer from the rendering issue by getting whited out. 


    That's part of the workaround.


    To resolve the issue completely (at least visually) I have a
    receive object in each GOP abstraction which acts as a global
    message bus to all GOPs. This bus is connected to a namecanvas
    send and sends a vis 0 and vis 1 message to turn the (and each
    and every) GOP's visibility on/off. 


    There is probably a more elegant solution .. which I'll post
    when/if I figure it.


    Best

    On 06/07/2011, at 12:! 22 PM, Hans-Christoph Steiner wrote:

    > 
    > 
    > Hey Christian
    > 
    > 
    > Thanks for the thorough bug report, the video is great.  I
    > think that's a known bug, or at least it seems familiar to
    > me.  It would be great to have this info in the bug tracker
    > so we can keep track of it.  This bug seems similar:
    > 
    > 
    > https://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=55736&atid=478070
    > 
    > 
    > If that's not it, then feel free to create a new bug report
    > in the tracker.
    > 
    > 
    > .hc
    > 
    > On Jun 28, 2011, at 10:51 PM, Christian Haines wrote:
    > 
    > Hi All
    > 
    > 
    > I have created an GOP abstraction which I include in a
    > parent parent. The GOP interface has a button that resizes
    > it by sending a 'coords' message to the GOP abstraction
    > canvas (namecanvas named). When it resizes larger it renders
    > the larger interface properly over the patch's white
    > background. However, when it resizes smaller it leaves a
    > remnant of the larger interface visible. Sometimes to
    > correctly show the smaller interface, I have to redraw /
    > refresh the window by moving the window - this doesn't
    > always work though. In fa! ct it only works when the parent
    > patch has a '#coords' line with a specific configuration in
    > it - of which I'm not sure.  I'm on OSX. I've seen the issue
    > documented elsewhere but never read a full description on
    > how to resolve it fully.
    > 
    > 
    > See the issue
    > here: http://echoblue.com.au/pd/goprenderissue.mov
    > 
    > 
    > 
    > 
    > At the mo! ment I am sending a message back to the parent
    > patch from the GOP abstraction to change the parent patch's
    > 'setbounds' by 1 pixel and then move it back - this resolves
    > that issue but, as mentioned, not consistently. Regardless,
    > it creates two more issues: (1) setbounds behaves oddly -
    > doesn't resize until a close and reopen; and/or moves the
    > objects in the patch window without resizing; (2) I can't
    > know the patch window size dynamically (say by querying the
    > canvas) hence any size change by setbounds is not
    > necessarily the same as the original window size (if it was
    > resizing!).
    > 
    > 
    > Any suggestions would be greatly appreciated
    > 
    > 
    > --
    > Christian
    > 
    > 
    > 
    > 
    > _______________________________________________
    > Pd-list@iem.at mailing list
    > UNSUBSCRIBE and account-management ->
    > http://lists.puredata.info/listinfo/pd-list
    > 




    ----------------------------------------------------------------------------


    Terrorism is not an enemy.  It cannot be defeated.  It's a
    tactic.  It's about as sensible to say! we declare war on
    night attacks and expect we're going to win that war.  We're
    not going to win the war on terrorism.        - retired U.S.
    Army general, William Odom

-- Christian Haines

Lecturer / Co-Director Electronic Music Unit

Elder Conservatorium of Music University of Adelaide South Australia 5005

Ph: +61 8 8303 3799 Fax: +61 8 8303 4423 Email: christian.haines@adelaide.edu.au Web: http://emu.adelaide.edu.au http://music.adelaide.edu.au Study: http://emu.adelaide.edu.au/study/ Location: Schulz Building, Level 5 , 5.13

---

CRICOS Provider Number 00123M

This email message is intended only for the addressee(s) and contains information that may be confidential and/or copyright. If you are not the intended recipient please notify the sender by reply email and immediately delete this email. Use, disclosure or reproduction of this email by anyone other than the intended recipient(s) is strictly prohibited. No representation is made that this email or any attachments are free of viruses. Virus scanning is recommended and is the responsibility of the recipient.

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Jonathan Wilkes jancsika@yahoo.com wrote:

I tested the patch from http://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=557... with pd-l2ork (Pd version 0.42.5-extended-l2ork-20110427) and every time I clicked the tgl in the parent patch it put me into edit mode. (Doesn't do that in pd vanilla).

Thanks for the report. Allow me to investigate.

Also, selecting and deselecting the tgl when it has a label gives an error to the terminal from which I'm running pd-l2ork: unknown option "-fill"

I have seen this before and I traced it down to tcl/tk. The command is in iemgui objects to allow for global custom colors. The irony is tcltk interprets the flag correctly and online documentation suggests this is a valid flag for the said widget but for some reason it keeps triggering those errors in the console.

-Jonathan

--- On Thu, 7/7/11, Ivica Ico Bukvic ico@vt.edu wrote:

From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] GOP Rendering Issue To: "Christian Haines" christian.haines@adelaide.edu.au, Pd-list@iem.at Date: Thursday, July 7, 2011, 8:47 AM

Neither if those are fixes but rather hacks that should be avoided because once the bug is fixed you will have to go back and change all your existing patches with this workaround. Pd already redraws entire gop object every time you move it or change its properties. I think this is because of out-of-order redrawing bug that persists in pd (at least it did since last time I checked). If you can please send a simplified version of the actual patch to test it in the l2ork iteration of pd which has afaik all known gop issues fixed, that could shed some light where the problem lies.

Ivica Ico Bukvic, D.M.A

Composition, Music Technology

Director, DISIS Interactive Sound & Intermedia Studio

Director, L2Ork LinuxLaptop Orchestra

Assistant Co-Director, CCTAD

CHCI, CS, and Art (by courtesy)

Virginia Tech

Department of Music

Blacksburg, VA 24061-0240

(540) 231-6139

(540) 231-5034 (fax)

disis.music.vt.edu

l2ork.music.vt.edu

ico.bukvic.net

Christian Haines christian.haines@adelaide.edu.au wrote: Thanks. I have added a comment to that bug report.  I note somewhere else on the list suggested using a kind of 'whiteout' approach by moving a white canvas over the the offending items prior to resizing - after resizing the canvas 'looks' ok. In short, visually this solves the issue, but if you do this overlapping other objects / GOPs etc then they suffer from the rendering issue by getting whited out.  That's part of the workaround.

To resolve the issue completely (at least visually) I have a receive object in each GOP abstraction which acts as a global message bus to all GOPs. This bus is connected to a namecanvas send and sends a vis 0 and vis 1 message to turn the (and each and every) GOP's visibility on/off.  There is probably a more elegant solution .. which I'll post when/if I figure it. Best On 06/07/2011, at 12:! 22 PM, Hans-Christoph Steiner wrote:

Hey Christian Thanks for the thorough bug report, the video is great.  I think that's a known bug, or at least it seems familiar to me.  It would be great to have this info in the bug tracker so we can keep track of it.  This bug seems similar: https://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=55... If that's not it, then feel free to create a new bug report in the tracker. .hc On Jun 28, 2011, at 10:51 PM, Christian Haines wrote:

Hi All I have created an GOP abstraction which I include in a parent parent. The GOP interface has a button that resizes it by sending a 'coords' message to the GOP abstraction canvas (namecanvas named). When it resizes larger it renders the larger interface properly over the patch's white background. However, when it resizes smaller it leaves a remnant of the larger interface visible. Sometimes to correctly show the smaller interface, I have to redraw / refresh the window by moving the window - this doesn't always work though. In fa! ct it only works when the parent patch has a '#coords' line with a specific configuration in it - of which I'm not sure.  I'm on OSX. I've seen the issue documented elsewhere but never read a full description on how to resolve it fully. See the issue here: http://echoblue.com.au/pd/goprenderissue.mov

At the mo! ment I am sending a message back to the parent patch from the GOP abstraction to change the parent patch's 'setbounds' by 1 pixel and then move it back - this resolves that issue but, as mentioned, not consistently. Regardless, it creates two more issues: (1) setbounds behaves oddly - doesn't resize until a close and reopen; and/or moves the objects in the patch window without resizing; (2) I can't know the patch window size dynamically (say by querying the canvas) hence any size change by setbounds is not necessarily the same as the original window size (if it was resizing!). Any suggestions would be greatly appreciated

--Christian

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.  It's about as sensible to say! we declare war on night attacks and expect we're going to win that war.  We're not going to win the war on terrorism.        - retired U.S. Army general, William Odom

--Christian Haines Lecturer / Co-DirectorElectronic Music Unit Elder Conservatorium of MusicUniversity of AdelaideSouth Australia  5005 Ph: +61 8 8303 3799Fax: +61 8 8303 4423Email: christian.haines@adelaide.edu.auWeb: http://emu.adelaide.edu.au%C2%A0%C2%A0        http://music.adelaide.edu.auStudy: http://emu.adelaide.edu.au/study/Location:%C2%A0Schulz Building, Level 5 , 5.13

-----------------------------------------------------------CRICOS Provider Number 00123M-----------------------------------------------------------This email message is intended only for the addressee(s) and contains information that may be confidential and/or copyright. If you are not the intended recipient please notify the sender by reply email and immediately delete this email. Use, disclosure or reproduction of this email by anyone other than the intended recipient(s) is strictly prohibited. No representation is made that this email or any attachments are free of viruses. Virus scanning is recommended and is the responsibility of the recipient.

-----Inline Attachment Follows-----

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

--- On Thu, 7/7/11, Ivica Ico Bukvic ico@vt.edu wrote:

From: Ivica Ico Bukvic ico@vt.edu Subject: Re: [PD] GOP Rendering Issue To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Christian Haines" christian.haines@adelaide.edu.au, Pd-list@iem.at Date: Thursday, July 7, 2011, 9:10 PM On Thu, 2011-07-07 at 09:32 -0700, Jonathan Wilkes wrote:

...

I tested the patch from http://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=557... with pd-l2ork (Pd version

0.42.5-extended-l2ork-20110427)

...

and every time I clicked the tgl in the parent patch

it put me into

...

edit mode. (Doesn't do that in pd vanilla).

OK, I just investigated this and the reason the edit mode is enabled because I never encountered a need to dynamically change GOPs this way and thus treated changes in canvas properties as editing of a patch which (as a courtesy) automatically enables editing mode. The same goes for editing of any other object's properties. e.g. create a vslider, exist the editing mode, right-click on the vslider and select properties, and the editing mode will be automatically enabled.

Ok, now that I understand how it works, that's not a bad assumption, IMO. If people want to do dynamic GOP sizing they can just use the "coords" message instead of "donecanvasdialog". (And I checked in Pd-l2ork, and "coords" doesn't change to edit mode, so this should work fine.)

If you think this should not be the case we are facing a discrepancy--whereas some editing actions automatically enable editing mode, others don't.

I think "coords" behavior should stay as it is, and this will be consistent:

vsl "size" message = no edit mode change

is like:

canvas "coords" message = no edit mode change

and:

bringing up vsl dialog = edit mode

is like:

bringing up subpatch/canvas dialog = edit mode

So even though the user can technically send a "donecanvasdialog" message, in doing so they are simulating whatever happens when you close the canvas dialog box (and getting whatever behavior becomes associated with that). In other words, there's no good reason for a user to send "donecanvasdialog" manually (right?).

-Jonathan

So, we need to figure out if we're going to be consistent one way or the other. Hans mentioned something about a performance mode in the latest pd-extended. Perhaps that would mean that the courtesy auto-editing would be then supplanted with strict editing mode which when disabled would grey-out (disable) all options that are associated with editing.

Best wishes,

Ico

--- On Fri, 7/8/11, Ivica Ico Bukvic ico@vt.edu wrote:

From: Ivica Ico Bukvic ico@vt.edu Subject: RE: [PD] GOP Rendering Issue To: "'Jonathan Wilkes'" jancsika@yahoo.com Cc: "'Christian Haines'" christian.haines@adelaide.edu.au, Pd-list@iem.at Date: Friday, July 8, 2011, 4:54 PM

...

Ok, now that I understand how it

works, that's not a bad assumption, IMO.

...

If people want to do dynamic GOP sizing they can just

use the "coords"

...

message instead of "donecanvasdialog".  (And I

checked in Pd-l2ork,

...

and "coords" doesn't change to edit mode, so this

should work fine.)

snip

...

So even though the user can technically send a

"donecanvasdialog"

...

message, in doing so they are simulating whatever

happens when you

...

close the canvas dialog box (and getting whatever

behavior becomes

...

associated with that).  In other words, there's

no good reason for a user

...

to send "donecanvasdialog" manually (right?).

Makes perfect sense. I already added fix for the cords to pd-l2ork so that part should be taken care of and everything should work as expected.

What the fix for the cords?

Best wishes,

Ico

On Thu, 7 Jul 2011, Ivica Ico Bukvic wrote:

OK, I just investigated this and the reason the edit mode is enabled because I never encountered a need to dynamically change GOPs this way and thus treated changes in canvas properties as editing of a patch which (as a courtesy) automatically enables editing mode. The same goes for editing of any other object's properties. e.g. create a vslider, exist the editing mode, right-click on the vslider and select properties, and the editing mode will be automatically enabled.

Btw, GF documentation uses 'coords' and also renders things differently when in edit-mode. It would be bad if 'coords' set the edit mode.

| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC

hey there,

i'm trying to implement a "hard-light" blending mode, as described on between two textures using a glsl fragment shader. it's compiling, linking and running fine in ShaderMaker. when i try to load it with [glsl_fragment] i don't seem to be getting an ID on the right outlet though. it never changes from [ 0] which i take to mean "failure in some way". the same happens, by the way, with the shaders, both vertex and fragment, that come in example/data.

a print message on glsl_fragment produces: [glsl_fragment]: ============================ [glsl_fragment]: MAX_FRAGMENT_UNIFORM_COMPONENTS: 2048 [glsl_fragment]: MAX_TEXTURE_COORDS: 8 [glsl_fragment]: MAX_TEXTURE_IMAGE_UNITS: 32

seems to be telling me, glsl support is acknowledged to be there.

i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10 with corporate nvidia driver, version: 260.19.44

any ideas anyone?

and then i have another question: if i manage to run the shader, how would i throw the two textures to their respective 2Dsamplers in there? prefix [pix_dump] output with the samplers name?

thanks+ciao, ub

On 24.07.2011 17:35, cyrille henry wrote:

Hello,

First, let's try to have the example to work. did you have any error when clicking on the "load shader" bang on the 1st example (01.simple texture)?

nop. no errors, but apparantly no shaders, also there. the only error i can get is with print from [glsl_program], "no GLSL-program linked".

for multi texture example, see example 5...

doh! thanks for pointing me there, though. ;)

hey there,

On 25.07.2011 09:26, IOhannes m zmoelnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-07-24 17:05, ub@xdv.org wrote:

...

i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10

there are some known problems with shaderID->t_float mapping on 64bit

i thought at some point one should leave the 32bit comfort zone.

systems which are fixed in current trunk.

ok, i did the svn update, but now i can't build Gem anymore. make fails pretty soon, saying: Dylib.cpp: In function ‘std::string getFullfilename(const _glist*, const char*, const char*)’: Dylib.cpp:157: error: ‘canvas_open’ was not declared in this scope

svn log tells me these files have been worked on recently, so it might not be entirely my ignorance.

thanks+ciao, ub

On 25.07.2011 15:04, IOhannes m zmoelnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-07-25 14:51, ub@xdv.org wrote:

...

hey there,

On 25.07.2011 09:26, IOhannes m zmoelnig wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 2011-07-24 17:05, ub@xdv.org wrote:

...

i'm running: pd-0.42.5-extended my gem version is: 0.92.3 on x86_64 ubuntu 10.10

there are some known problems with shaderID->t_float mapping on 64bit

i thought at some point one should leave the 32bit comfort zone.

...

systems which are fixed in current trunk.

ok, i did the svn update, but now i can't build Gem anymore. make fails pretty soon, saying: Dylib.cpp: In function ?std::string getFullfilename(const _glist*, const char*, const char*)?: Dylib.cpp:157: error: ?canvas_open? was not declared in this scope

svn log tells me these files have been worked on recently, so it might not be entirely my ignorance.

indeed :-)

however, i have the feeling, that your compiler simply cannot find m_pd.h (and you did not give us the full error message that would have said that)

i did give the --with-pd option as ../pd/src so ./configure did not complain in the first place. weirdly now trying to reproduce it, libtool says, it can't determine the absolute directory name. i swear, that wasn't there before. :D

i don't know where pd-extended puts its headers, you might try something like: $ ./configure --with-pd=/usr/include/pdextended/

anyway ... it did compile, it did install, the shader examples work and my shader also more or less works. joo!

and don't forget, that now the entire build process is in ...gem/ rather than ...gem/src/

saw that. :)

thanks for the help!

ciao, ub

hey there again,

i basically got my shader running, it was a bit of a challenge, because i realized i had to use rectangle texunits, as the input is classic 4:3 video frames.

so fine, i did this, but now the output of pix_progam is acting kind of weird. it seems to be a proper pix structure, when i attach a pix_info to it, it's the correct resolution and type. it is possible that it is still an bug in my shader, but for instance i see in the example patch 06.rectangle_multitexture that there is a pix_set right after the pix_program and also in my patch things dont work correctly when i don't put it there. i wonder what it's needed for.

still with the thing in place, the texturing behaves strange. for example, if i put an object like pix_contrast or pix_add in it's way, i only see some blue flashing. the flashing seems like one pixel of the texture magnified to the whole surface. so i thought it's the texture coordinates and i tried pix_coordinates to correct them without success.

then the texture won't display on pix_draw at all, which is fine, i can live without it.

pix_flip doesn't do anything but it doesn't screw up the texture.

when i use the output of the rectangle_multitexture example i have basically the same effects slightly different in some cases.

maybe i'm missing something obvious, i have tried a lot and i will continue to look, but if someone knows more about this i'd be happy with some explanations.

thanks+ciao, ub