-
-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ebiten: remove *ebiten.Image
functions that are needed for image.Image
#2945
Comments
#2902 might be related |
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. |
Yeah, this additional function call is an intentional change to make the execution cost more explicit. |
As long as indexed bitmaps are properly supported both ways, this is fine by me |
I have no idea about the bitmap editor, so I cannot say anything about this. |
As Another possible idea is to make type ReadPixelsResult struct {
Bytes []byte
Err error
}
func (*Image) ReadPixels(buf []byte) (<-chan ReadPixelsResult) |
I have a few questions:
|
To avoid or reduce internal allocations.
The graphics driver might fail for some reasons. In most cases there is nothing a user can do.
No, adding a returning value breaks the compatibility. There can be an interface that defines ReadPixels. |
Will the allocated |
Yes and no. We can treat this like |
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. |
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. |
Operating System
What feature would you like to be added?
*ebiten.Image
now implementsimage.Image
which includesAt
andColorModel
. EspeciallyAt
is problematic asAt
seems handy though it is very expensive to sync pixel data from GPU to CPU. So, we don't want encourage users to useAt
.*ebiten.Image
implementingimage.Image
was not a good API in terms of execution costs.Thus, we propose these API changes.
(*ebiten.Image).At
(*ebiten.Image).RGBA64At
(*ebiten.Image).ColorModel
(*ebiten.Image).Set
draw.Image
, but as*ebiten.Image
is no longerimage.Image
, I don't think we have to have this.(*ebiten.Image).SubImage
return an*ebiten.Image
instead ofimage.Image
*ebiten.Image
is no longerimage.Image
, we no longer need to follow this.(*ebiten.Image).ReadPixels
return an errorAt
couldn't return an error and Ebitengine accumulated an error in the internal. AsAt
is removed, we no longer need to have such a hack.func Image(*ebiten.Image) image.Image
toebitenutil
(orScreenshot
orDump
?)(*ebiten.Image).ReadPixels
, we can put a utility function to create animage.Image
in a utility package, rather than the core package.As these are breaking changes, we will do in v3.
/CC @Zyko0 @superloach @tinne26
Why is this needed?
An expensive API should not be handy since people often misuse such APIs.
The text was updated successfully, but these errors were encountered: