Bugs item #3313799, was opened at 2011-06-08 14:38
Message generated for change (Comment added) made by nusmuk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: example 04.pix/26.framebuffer_readback crash
Initial Comment:
the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows
this is with curent svn (rev 3971), ubuntu 10.04
I can see 2 different problem :
- pix_snap does not create an image (pix_info after pix_snap gives only -1)
- pix_buffer_read crash when reading this image
----------------------------------------------------------------------
>Comment By: Cyrille Henry (nusmuk)
Date: 2011-06-08 18:44
Message:
nvidia driver
intel i7
kernel 2.6.32 / 64 bit
pix_snap does not work for framebuffer, but pix_write is working...
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-06-08 18:01
Message:
weird; i'm unable to reproduce the problem.
which drivers? which architecture?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…
Bugs item #3313799, was opened at 2011-06-08 16:38
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: example 04.pix/26.framebuffer_readback crash
Initial Comment:
the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows
this is with curent svn (rev 3971), ubuntu 10.04
I can see 2 different problem :
- pix_snap does not create an image (pix_info after pix_snap gives only -1)
- pix_buffer_read crash when reading this image
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-06-08 20:01
Message:
weird; i'm unable to reproduce the problem.
which drivers? which architecture?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…
Bugs item #3313799, was opened at 2011-06-08 14:38
Message generated for change (Tracker Item Submitted) made by nusmuk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: example 04.pix/26.framebuffer_readback crash
Initial Comment:
the example 04.pix/26.framebuffer_readback crash pd with a segfault when creating the openGL windows
this is with curent svn (rev 3971), ubuntu 10.04
I can see 2 different problem :
- pix_snap does not create an image (pix_info after pix_snap gives only -1)
- pix_buffer_read crash when reading this image
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3313799&group_…
Bugs item #3308535, was opened at 2011-05-27 21:50
Message generated for change (Comment added) made by katjav
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3308535&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: linux
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_image eats a lot of CPU even when idle
Initial Comment:
If you have many [pix_image] objects in a patch, even if none of them loads any image and even if none of them is connected to any gemhead, Pd will consume a lot of CPU, apparently proportional to the number of [pix_image] instances.
On a dual core machine, the amount of CPU consumption can exceed 100% of a core, so I guess the issue must be in some part of the code that is threaded - hopefully this may help to track down the issue.
The attached patch (64 pix_images) eats 150% of my intel core duo t9300 on Ubuntu 10.04 while the patch is doing absolutely nothing.
This makes it impossible to have a handful of pix_image objects with preloaded images and dynamically choose which one to show, just to name one thing that can't be done and which should not be resource-demanding. This kills any project working with images.
----------------------------------------------------------------------
Comment By: Katja (katjav)
Date: 2011-06-08 13:08
Message:
Confirm this issue for Debian Squeeze. pix_image causes a cpu load of ~4%
per instance when thread loading is enabled.
Debian Squeeze
Panasonic CF 74 with Intel integrated 945GM
Pd-extended 0.42.5
Gem 0.93
Since thread loading is enabled by default, patches with multiple
pix_image created on other systems (where this issue does not exist) can
not be used without modification. If the pix_image cpu load issue is common
for Linux, the object should initialize with threadMess(0) instead of
threadMess(1) as long as the issue is not solved. I recompiled Gem with
this small change in the code and can now load arbitrary patches with
multiple pix_image. Cross-platform patch sharing would be better served by
source and binary distributions with this initialisation, until the issue
can be solved in a more satisfactory way.
Katja Vetter
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-05-27 22:12
Message:
I've just realised that if I send [pix_image] a "thread 0" message it stops
eating CPU.
So it is the threaded mode. Note that there's no need to actually load an
image to trigger the issue: just because threaded mode is enabled, it is
always wasting CPU.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3308535&group_…
Feature Requests item #3311982, was opened at 2011-06-05 17:41
Message generated for change (Comment added) made by nusmuk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: openGL
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: max (maxn)
Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: mesh_square, cuve3d accept different messages
Initial Comment:
curve3d accepts draw fill, line, point, line1, line2, line3 line4 messages while mesh_square accepts draw default, line and point but no mesh (fill) at all though the name suggests that a mesh looks like a mesh. it would be nice if mesh_square could have a mesh and those commands would be better standardized.
----------------------------------------------------------------------
Comment By: Cyrille Henry (nusmuk)
Date: 2011-06-05 18:50
Message:
I agree that curve3d draw message name are poorly chosen.
and I also agree that mesh_square is missing some draw messages.
I think we need some brain storming to choose good label for curve3d draw
messages, and then use the same message for mesh_square.
since I code both objects, I don't have any better suggestion for this
messages.
but i can code them.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&group_…
Feature Requests item #3311982, was opened at 2011-06-05 17:41
Message generated for change (Tracker Item Submitted) made by maxn
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: openGL
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: max (maxn)
Assigned to: IOhannes m zmlnig (zmoelnig)
Summary: mesh_square, cuve3d accept different messages
Initial Comment:
curve3d accepts draw fill, line, point, line1, line2, line3 line4 messages while mesh_square accepts draw default, line and point but no mesh (fill) at all though the name suggests that a mesh looks like a mesh. it would be nice if mesh_square could have a mesh and those commands would be better standardized.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507082&aid=3311982&group_…
hi,
I can't get pix_gst2pix to work on my machine (Ubuntu 10.04).
I tried the test patch gst2pix.pd but the texture stays blank...
I've put some post() in the code to try to track from where the bug comes
now I just know that all functions are well called
but pix_info sends only -1 on all outlets when I put it between pix_gst2pix
and pix_texture
even the 6th and 7th outlet are sending -1 whereas they used to send list...
and nothing is sent throught the 8th outlet
does anyone have any idea to fix this ?
thanks
antoine
--
do it yourself
http://antoine.villeret.free.frhttp://drii.ensad.fr
--
Google lit ce mail...
si vous refusez cela, utilisez l'adresse antoine.villeret [at] free.fr pour
me contacter
thanks Iohannes for the quick fix.
c
Le 01/06/2011 18:06, SourceForge.net a écrit :
> Bugs item #3309231, was opened at 2011-05-30 11:07
> Message generated for change (Comment added) made by zmoelnig
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_…
>
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: None
> Group: None
>> Status: Pending
>> Resolution: Fixed
> Priority: 5
> Private: No
> Submitted By: Cyrille Henry (nusmuk)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: RGB32 frambuffer can't be initialised with a loadbang
>
> Initial Comment:
> When sending "format RGB32" to gemframebuffer, a valid context have to be present. Otherwise, default RGB format is used.
>
> This was not the case prior to revision 3807.
>
> here is the relevant part of the diff (gemframbuffer.cpp)
>
> 398c398,400
> < tmp_format = GL_RGB_FLOAT32_ATI;
> ---
>> if(GLEW_ATI_texture_float) {
>> tmp_format = GL_RGB_FLOAT32_ATI;
>> }
>
>
> Since a loadbang is usually used to set the framebuffer format, this behaviors break all my patch that need 32bit framebuffer (including the GPGPU example)
>
> test patch in attachment.
>
> ----------------------------------------------------------------------
>
>> Comment By: IOhannes m zmlnig (zmoelnig)
> Date: 2011-06-01 18:06
>
> Message:
> thanks.
>
> this should be fixed with rev.3957
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_…
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev(a)iem.at
> http://lists.puredata.info/listinfo/gem-dev
>
Bugs item #3309231, was opened at 2011-05-30 11:07
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: RGB32 frambuffer can't be initialised with a loadbang
Initial Comment:
When sending "format RGB32" to gemframebuffer, a valid context have to be present. Otherwise, default RGB format is used.
This was not the case prior to revision 3807.
here is the relevant part of the diff (gemframbuffer.cpp)
398c398,400
< tmp_format = GL_RGB_FLOAT32_ATI;
---
> if(GLEW_ATI_texture_float) {
> tmp_format = GL_RGB_FLOAT32_ATI;
> }
Since a loadbang is usually used to set the framebuffer format, this behaviors break all my patch that need 32bit framebuffer (including the GPGPU example)
test patch in attachment.
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-06-01 18:06
Message:
thanks.
this should be fixed with rev.3957
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309231&group_…
Bugs item #3309225, was opened at 2011-05-30 10:50
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309225&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: None
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Cyrille Henry (nusmuk)
Assigned to: Nobody/Anonymous (nobody)
Summary: rectangle message to pix_texture brocken in some condition
Initial Comment:
In some specific condition, the rectangle message to pix_texture become useless.
One have to use shader in order to noticed this effect since texturing usually work in both mode.
Conditions that make the rectangle message to be brocken are mainly caused when pix_texture did not receive the gem_state 1 message.
So, if you initialize rectangle mode with a loadbang, and if you inhibit the gemhead during the windows creation, then pix_texture will never be able to switch to rectangle texture.
same problem when creating a patch : if you create pix_texture, and send it "rectangle 1" before connecting it on a gemhead, then it will never switch to rectangular texture.
here is a simple test patch.
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-06-01 16:38
Message:
thanks for the bug-report.
this issue should be fixed with rev.3955
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3309225&group_…