[Pharo-dev] [Vm-dev] pb with primitive #primitiveScreenDepth on Linux ?

Christophe Demarey christophe.demarey at inria.fr
Fri Feb 3 03:50:34 EST 2017


> Le 2 févr. 2017 à 21:31, Bert Freudenberg <bert at freudenbergs.de> a écrit :
> 
> I was thinking about if it's safe to ignore endianness in this VM primitive. And I think it's safe in 32 bpp, but not in lower bit depths.
> 
> #(1 -1 16 -16 32 -32) collect: [:d | ((Form extent: 1 at 1 depth: d) colorAt: 0 at 0 put: Color red; bits) first hex]
> 
> ==> #('16r80000000' '16r1' '16r7C000000' '16r7C00' '16rFFFF0000' '16rFFFF0000’)

#('16r80000000' '16r1' '16r7C000000' '16r7C00' '16rFFFF0000' '16rFFFF0000’)

same result in Pharo


> So from the image's perspective, there is no difference for little endian / big endian forms in the raw bitmap values in 32 bpp. 
> 
> And to the VM it looks the same. It just needs to know that on a little endian architecture it's BGRA while on big endian it's ARGB. Neither helps SqueakJS, because Javascript's Canvas.putImageData() uses RGBA. May be I should add a WebGL rendering path ... the swizzling would be easy in a fragment shader. 
> 
> - Bert -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170203/d38d8ecc/attachment.html>


More information about the Pharo-dev mailing list