<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 2 févr. 2017 à 21:31, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" class="">bert@freudenbergs.de</a>> a écrit :</div><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">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.</div><div class=""><div class=""><br class=""></div><div class="">#(1 -1 16 -16 32 -32) collect: [:d | ((Form extent: 1@1 depth: d) colorAt: 0@0 put: Color red; bits) first hex]</div><div class=""><br class=""></div><div class="">==> #('16r80000000' '16r1' '16r7C000000' '16r7C00' '16rFFFF0000' '16rFFFF0000’)</div></div></div></div></div></div></blockquote><div><br class=""></div><div>#('16r80000000' '16r1' '16r7C000000' '16r7C00' '16rFFFF0000' '16rFFFF0000’)</div><div><br class=""></div><div>same result in Pharo</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">So from the image's perspective, there is no difference for little endian / big endian forms in the raw bitmap values in 32 bpp. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">- Bert -</div></div></div></div></blockquote></div><br class=""></body></html>