implement setImpl() instead of set() inside PGraphicsOpenGL #160

Closed
processing-bugs opened this Issue Feb 10, 2013 · 5 comments

Comments

Projects
None yet
3 participants
@processing-bugs

Original author: b...@processing.org (June 07, 2010 01:06:41)

This bug automatically added from:
http://dev.processing.org/bugs/show_bug.cgi?id=943

Comment from fry, 2008-10-05 20:23

setImpl() is more efficient because it'll properly handle cropping and
placement.

Original issue: http://code.google.com/p/processing/issues/detail?id=121

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From andres.c...@gmail.com on November 20, 2012 18:53:13
Right now setImpl() in PGraphicsOpenGL does:

protected void setImpl(int dx, int dy, int sx, int sy, int sw, int sh, PImage src) {
loadPixels();
setgetPixels = true;
super.setImpl(dx, dy, sx, sy, sw, sh, src);
}

Since PImage.setImpl() is called, slow pixel copy is still used. It could be re-implemented using texture blitting. Should I do that?

From andres.c...@gmail.com on November 20, 2012 18:53:13
Right now setImpl() in PGraphicsOpenGL does:

protected void setImpl(int dx, int dy, int sx, int sy, int sw, int sh, PImage src) {
loadPixels();
setgetPixels = true;
super.setImpl(dx, dy, sx, sy, sw, sh, src);
}

Since PImage.setImpl() is called, slow pixel copy is still used. It could be re-implemented using texture blitting. Should I do that?

@processing-bugs

This comment has been minimized.

Show comment
Hide comment
@processing-bugs

processing-bugs Feb 10, 2013

From f...@processing.org on November 20, 2012 18:57:48
Yes, that's the idea. The set() method takes care of things like imageMode() (if that's supported...it's not for set()) or any other state information. setImpl() is the renderer-specific code that can be overridden to make things faster. In PGraphics, there's a version of some methods that's slow but should always work, then the Impl functions override to do renderer-specific versions.

From f...@processing.org on November 20, 2012 18:57:48
Yes, that's the idea. The set() method takes care of things like imageMode() (if that's supported...it's not for set()) or any other state information. setImpl() is the renderer-specific code that can be overridden to make things faster. In PGraphics, there's a version of some methods that's slow but should always work, then the Impl functions override to do renderer-specific versions.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Jun 3, 2013

Member

Right now what happens is the following: copy the pixels array of sourceImage into the pixels array of PGraphicsOpenGL using PGraphics.setImpl(), and then upload the pixels array to the texture using texSubImage2D(). The (faster) way would be to copy the pixels of sourceImage into the pixels array of PGraphicsOpenGL (same as before) and then blit the texture cache of sourceImage into the PGraphicsOpenGL surface (this should be faster than texSubImage2D).

The current implementation is working correctly, so will tag this as low priority for post-2.0 enhancements.

Member

codeanticode commented Jun 3, 2013

Right now what happens is the following: copy the pixels array of sourceImage into the pixels array of PGraphicsOpenGL using PGraphics.setImpl(), and then upload the pixels array to the texture using texSubImage2D(). The (faster) way would be to copy the pixels of sourceImage into the pixels array of PGraphicsOpenGL (same as before) and then blit the texture cache of sourceImage into the PGraphicsOpenGL surface (this should be faster than texSubImage2D).

The current implementation is working correctly, so will tag this as low priority for post-2.0 enhancements.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
Member

codeanticode commented May 31, 2015

@benfry

This comment has been minimized.

Show comment
Hide comment
@benfry

benfry Jun 1, 2015

Member

Great to see these getting closed out! Nice work.

Member

benfry commented Jun 1, 2015

Great to see these getting closed out! Nice work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment