Skip to content
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

TexPlay.create_image() unnecessarily slow due to caching #11

Open
banister opened this issue Dec 2, 2010 · 2 comments
Open

TexPlay.create_image() unnecessarily slow due to caching #11

banister opened this issue Dec 2, 2010 · 2 comments
Labels

Comments

@banister
Copy link
Owner

banister commented Dec 2, 2010

since create_image does a rect() (to 'fill' the new image with a color) it always performs a cache AND a sync which is incredibly expensive. We can remove both the cache and sync if we instead rely on a blob's own color information. But this may mean we have to accept colors in all possible texplay formats ? Alternatively, get rid of create_image() ability to set color at all.

@bil-bas
Copy link
Collaborator

bil-bas commented Dec 2, 2010

It is easy to convert to-from gosu colours, but yes, would be a bit more work to parse the named colours (depending how easy it would be to read them from the C file with a little script, say). Removing the colour rect isn't a bad idea, since you can always use #clear to colour fill (which is nice and concise compared to manually using #rect after the create). I am pretty sure I do specify colour in create in my code somewhere, but it isn't that important that the colour can be specified if it is in there.

Alternatively, a simpler option would be to check if the colour == [255, 255, 255, 0] or [1.0, 1.0, 1.0, 0.0] or :alpha and not do the rect. I suspect most usage of the #create_image would be for this and it wouldn't require the amount of logic required for checking all possible colours.

While there, I'd suggest making a Gosu::Image.create() or overload for #new that does the same thing as create_image.

@banister
Copy link
Owner Author

banister commented Dec 2, 2010

yep, i went with exactly your last suggestion in the end, cheers :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants