loadImage() requires a PGraphics which makes API harder to use

[jdf]

There's no way to call loadImage() from outside of setup() or other blessed main thread methods because of

https://github.com/processing/processing/blob/master/core/src/processing/core/PApplet.java#L5250

but, if I understand correctly from following the code around, this is just to guard against certain circumstances when concurrently loading images from the network. In the case of trying to create an image from a local data file, can't that check be skipped?

[JakubValtar]

Hi @jdf, can you give me a short example?

The check is there because we have asynchronous saving and some people like to call loadImage() right after saving it, in which case we have to block until the saving is finished, otherwise the image gets corrupted.

If there is a good reason to call loadImage() from other threads, I can make it thread safe.

[jdf]

Sure. Several Python Mode examples were broken by this commit, but the general form is

img = loadImage('banana.jpg')

def setup():
     size(300, 300)

def draw():
    image(img, 0, 0)

[jdf]

Is there a reason that the PGraphics has to be the synchronization provider?

[JakubValtar]

You still won't be able to load banana.jpg before setup(), because sketch path is not initialized yet.

Sure. Several Python Mode examples were broken by this commit,

I just tried Topics - Image Processing - Blending and it was already broken in 3.0, because it can't find the files without the sketch path. There is a reason why Java Mode examples never load images before setup(). Loading anything before setup() will only work for absolute pats (and possibly web addresses).

Is there a reason that the PGraphics has to be the synchronization provider?

Yes, PGraphicsOpenGL launches DMA transfers to get pixels from graphics card without blocking the cpu and it has to complete them on the rendering thread.

However, it can be solved to make it work in your case, that is not the problem. Sketch path is going to be your problem, and I don't think we can solve that one.

[jdf]

Thanks very much for your detailed answers. While it happens to be the case that sketch path is indeed available for a Python mode sketch from the get-go, I understand that it may not be convenient to make it so for Java mode. Again, thanks for your consideration.

[JakubValtar]

Thanks very much for your detailed answers.

You're welcome!

While it happens to be the case that sketch path is indeed available for a Python mode sketch from the get-go

Not on my machine. Python mode in Processing 3.0.2 just loads null and crashes with NullPointerException when I try to draw the image.

img1 = loadImage("layer1.jpg")

def setup():
    size(640, 360)

def draw():
    background(0)
    image(img1, 0, 0)  # NullPointerException here

When I move the loadImage into setup(), it works.

def setup():
    size(640, 360)
    global img1
    img1 = loadImage("layer1.jpg")

def draw():
    background(0)
    image(img1, 0, 0)  # works

It might just be a coincidence on your side (maybe you are launching processing from the sketch folder), but generally sketch path before setup() (more precisely before settings()) is undefined, and you should probably update your examples accordingly. Java mode prints a warning that sketch path is not defined yet and you should move the initializer into setup().

Again, thanks for your consideration.

I would also liked if it just worked everywhere, but sadly it's not possible with the current architecture.

[jdf]

How about with an up-to-date processing? What build of Python Mode? Anyway, it won't work anymore at all, so it's mooooooot.

[JakubValtar]

Python mode 3015. Nope, doesn't work with 3.0 nor with 3.1.1 (where I fixed the problem with PGraphics you mentioned). It just tells me files are not accessible and then crashes with NullPonterException when I try to draw the image (which is null). However, I don't see how it could have worked in the past, unless it's some coincidence in OSX version.

[jdf]

Well then. That seems to be that!

[JakubValtar]

Yeah... sorry.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.