search

banister / texplay

image manipulation tool for ruby and gosu
66 stars 16 forks source link

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

Open banister opened 13 years ago

banister commented 13 years ago

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 commented 13 years ago

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 commented 13 years ago

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