<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 2, 2017 at 10:44 AM, Christophe Demarey <span dir="ltr"><<a href="mailto:christophe.demarey@inria.fr" target="_blank">christophe.demarey@inria.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br><div style="word-wrap:break-word">Hello Bert,<div><br><div><blockquote type="cite"><div>Le 31 janv. 2017 à 18:18, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>> a écrit :</div><br class="gmail-m_-7698610481587113737Apple-interchange-newline"><div><div dir="ltr" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 31, 2017 at 10:44 AM, Christophe Demarey<span class="gmail-m_-7698610481587113737Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:christophe.demarey@inria.fr" target="_blank">christophe.demarey@<wbr>inria.fr</a>></span><span class="gmail-m_-7698610481587113737Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Hello,<br><br>With Pavel, we discovered a strange behavior of the primitive #primitiveScreenDepth on Linux. It returns a value of 24 bits per pixel (True colors) that looks valid but not supported (at least by Pharo).<br><br>DisplayScreen actualScreenDepth "(calling the primitive screenDepth)"<br>       <span class="gmail-m_-7698610481587113737Apple-converted-space"> </span>=> 32 on OS X [OK]<br>       <span class="gmail-m_-7698610481587113737Apple-converted-space"> </span>=> 24 on Linux [KO]<br><br>Also, it is not consistent with the primitive 91<br><br>DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth<br>       <span class="gmail-m_-7698610481587113737Apple-converted-space"> </span>=> true on OS X<br>       <span class="gmail-m_-7698610481587113737Apple-converted-space"> </span>=> false on Linux<br><br>There are some safeguard image-side but it would be great if someone could check that vm side.<br></blockquote><div><br></div><div>That seems wrong indeed, since BitBlt can only handle power-of-two depths currently. It should answer 32 or -32 in this case. </div><div><br></div><div>Actually ... is there a difference in pixel layout for 32 bit MSB vs LSB forms? A quick test in SqueakJS suggests there isn’t.</div></div></div></div></div></blockquote><br></div><div>I do not get what you mean by 32 bits MSB vs LSB form. Could you give an example of what to test?</div><div>If you mean a difference between depth 32 or -32, I do not see any difference.</div></div></div></blockquote><div><br></div><div>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><div><br></div><div>#(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><br></div><div>==> #('16r80000000' '16r1' '16r7C000000' '16r7C00' '16rFFFF0000' '16rFFFF0000')</div></div><div><br></div><div>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><br></div><div>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><br></div><div>- Bert -</div></div></div></div>