Hi again, Benj, and thanks again for your reply.
Indeed, it'd be a good idea implement the setBezierVertex myself, but if I did that, I'd have to create a new shape everytime I want to draw it, by calling a new createShape everytime. That's in fact quite similar to how I had it firstly implemented, I already have a heart class created. I had hoped it was implemented in the PShape itself in an efficient way.
What I wanted to do is not having to create a new shape everytime I run into draw(), but taking advantage of the capacity to create one shape and just modifying its vertexs at every draw, so I could just create the PShape when creating a heart object, and then just modifying the vertexs at every step, so I can optimize the speed of my sketch, like Daniel Shiffman very well explains in the PShape tutorial. Take into account that my sketch is showing 50 or more shapes (hearts or other shapes) every frame and that they should grow one pixel or more per frame (I control the growing speed with a variable controlled by a midi interface). When the shape is quite big and it's filled, it may run a bit slower than my desired 30 fps, that's why I decided to change all my initial sketch that created a new shape everytime it had to display it by a PShape that I could alter a bit everyframe, but not creating it from scratch, hoping I could get some extra milliseconds that could help improving the speed of my sketch.
Just for you to have an idea of how this processing app is you can take a look to this video I made: http://www.youtube.com/watch?v=KbCRaY84-Ps. There are no heart shapes in this video but mainly 3D shapes (there are 2D triangles at the very end of the video, more like the hearts), the speed of the growing and the frequency of new shapes born are controlled by a midi interface by moving some sliders, so when I make them move and create really fast I may get some performance issues.
I think I'll have to stick in using scale() (or creating a new shape every frame). What I didn't like of scale() in this case is that, as it's cummulative, it was very difficult for me to calculate the new scaling factor for everyframe in order to make it grow in a consistent way, not having to resetMatrix() everytime. The shapes in my sketch appear rotated PI (upwards) every two shapes, and resetting the matrix would make me loose that rotation and have to rotate it again every frame is being drawn, loosing some extra milliseconds, when I could avoid that if it's already in the PShape. I solved that by creating the shape upside down already - not rotating it, but setting the vertex points upside down. And this way works pretty well.
I just hope Processing would allow us to control the bezier vertexs the same way we can control the other vertexs, as I said before, though I guess that converting them into normal vertexs when creating the shape is the way to really achieve more efficient shape manipulation by processing, java and the graphics interface.
Indeed, it'd be a good idea implement the setBezierVertex myself, but if I did that, I'd have to create a new shape everytime I want to draw it, by calling a new createShape everytime. That's in fact quite similar to how I had it firstly implemented, I already have a heart class created. I had hoped it was implemented in the PShape itself in an efficient way.
What I wanted to do is not having to create a new shape everytime I run into draw(), but taking advantage of the capacity to create one shape and just modifying its vertexs at every draw, so I could just create the PShape when creating a heart object, and then just modifying the vertexs at every step, so I can optimize the speed of my sketch, like Daniel Shiffman very well explains in the PShape tutorial. Take into account that my sketch is showing 50 or more shapes (hearts or other shapes) every frame and that they should grow one pixel or more per frame (I control the growing speed with a variable controlled by a midi interface). When the shape is quite big and it's filled, it may run a bit slower than my desired 30 fps, that's why I decided to change all my initial sketch that created a new shape everytime it had to display it by a PShape that I could alter a bit everyframe, but not creating it from scratch, hoping I could get some extra milliseconds that could help improving the speed of my sketch.
Just for you to have an idea of how this processing app is you can take a look to this video I made: http://www.youtube.com/watch?v=KbCRaY84-Ps. There are no heart shapes in this video but mainly 3D shapes (there are 2D triangles at the very end of the video, more like the hearts), the speed of the growing and the frequency of new shapes born are controlled by a midi interface by moving some sliders, so when I make them move and create really fast I may get some performance issues.
I think I'll have to stick in using scale() (or creating a new shape every frame). What I didn't like of scale() in this case is that, as it's cummulative, it was very difficult for me to calculate the new scaling factor for everyframe in order to make it grow in a consistent way, not having to resetMatrix() everytime. The shapes in my sketch appear rotated PI (upwards) every two shapes, and resetting the matrix would make me loose that rotation and have to rotate it again every frame is being drawn, loosing some extra milliseconds, when I could avoid that if it's already in the PShape. I solved that by creating the shape upside down already - not rotating it, but setting the vertex points upside down. And this way works pretty well.
I just hope Processing would allow us to control the bezier vertexs the same way we can control the other vertexs, as I said before, though I guess that converting them into normal vertexs when creating the shape is the way to really achieve more efficient shape manipulation by processing, java and the graphics interface.