Re: Graphics.drawImage() vs Graphics.drawRGB()

Thanks Eliot and Robin for your input. I'm not really worried about  
supporting some of the much older handsets. Motorola v525 is about as  
old / low spec as I go now.

I seem to have drawRegion() working OK on the k800 now, was just  
thought it would be a bit more elegant (and possibly faster) than the  
old clipRect/drawImage scenario which often involves a lot of method  
calls to remember and reset the original clip. Not really worried  
about transformations.

I'm particularly interested in the RGB stuff for creating semi- 
mutable transparent images, ie create a mutable image / do some  
drawing / make an immutable image from it and add transparency. This  
will be very useful particularly when rendering graphical fonts and  
the like and seems to work OK so far, thought it would probably be  
too much of a 'sledghammer' approach to do every frame. Shame about  
Graphics.drawRBG(), that would have been cool, too good to be true I  
guess...

Haven't tried messing about with raw PNG data but it's probably  
something I should look into.

cheers

> I recommend not using the RGB specific code on a per frame basis,  
> but generating the required assets
> at load time and using standard drawImage() calls.
>
> I generally work around this by loading the raw PNG bytes and  
> adding/modifying chunks if I need to
> change the pallete or image alpha.

====

James Closs, Director, bitBull Ltd

http://www.bitbull.com

07771 991171

====


===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff KVM-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".