ebiten: remove `*ebiten.Image` functions that are needed for `image.Image` about ebiten HOT 12 OPEN

Yeah, this additional function call is an intentional change to make the execution cost more explicit.

from ebiten.

I have no idea about the bitmap editor, so I cannot say anything about this.

from ebiten.

What is the role of the buf argument in this case?

To avoid or reduce internal allocations.

What is the case where ReadPixels returns an error, for example?

The graphics driver might fail for some reasons. In most cases there is nothing a user can do.

If we just add a return value, compatibility is certainly preserved, but if the signature is going to change, it would be more straightforward to change the function name.

No, adding a returning value breaks the compatibility. There can be an interface that defines ReadPixels.

from ebiten.

#2902 might be related

from ebiten.

For an indexed bitmap editor for pixel art it is handy that ebiten.Image is an image.Image. If this is removed we will need to add conversion functions in both ways.

from ebiten.

As long as indexed bitmaps are properly supported both ways, this is fine by me

from ebiten.

As ReadPixels is very special as it flushes the internal command queue, I might want to move this method to somewhere where we can call it in a limited situation (under Update or Draw). Actually, reading pixels was a blocker to implement handling events (#1704 (comment)).

Another possible idea is to make ReadPixels asynchronous:

type ReadPixelsResult struct {
    Bytes []byte
    Err   error
}

func (*Image) ReadPixels(buf []byte) (<-chan ReadPixelsResult)

from ebiten.

Another possible idea is to make ReadPixels asynchronous:

I have a few questions:

• What is the role of the buf argument in this case?
• What is the case where ReadPixels returns an error, for example?
• If we just add a return value, compatibility is certainly preserved, but if the signature is going to change, it would be more straightforward to change the function name.
• I think the "non-blocking" functions in Go take chan as an argument, not a return value (sorry if I'm wrong). I was wrong, functions like time.After return chan.

from ebiten.

To avoid or reduce internal allocations.

Will the allocated buf be written from another goroutine?

from ebiten.

Will the allocated buf be written from another goroutine?

Yes and no. We can treat this like append: if the buf is not enough, ReadPixels can extend the buffer.

from ebiten.

OK, thanks for responding. To be honest I am not sure about the design of the asynchronous API, but my opinion is in favor of this proposal.

from ebiten.

Another example of Go's non-blocking API is a Start/Wait pair like exec.Command, I'm not sure if it's appropriate for Ebitengine, but just FYI.

from ebiten.