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

[Bert Freudenberg]

On Thu, Feb 2, 2017 at 10:44 AM, Christophe Demarey <
christophe.demarey at inria.fr> wrote:

>
> Hello Bert,
>
> Le 31 janv. 2017 à 18:18, Bert Freudenberg <bert at freudenbergs.de> a écrit
> :
>
> On Tue, Jan 31, 2017 at 10:44 AM, Christophe Demarey <christophe.demarey@
> inria.fr> wrote:
>
>>
>> Hello,
>>
>> 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).
>>
>> DisplayScreen actualScreenDepth "(calling the primitive screenDepth)"
>>         => 32 on OS X [OK]
>>         => 24 on Linux [KO]
>>
>> Also, it is not consistent with the primitive 91
>>
>> DisplayScreen new supportsDisplayDepth: DisplayScreen actualScreenDepth
>>         => true on OS X
>>         => false on Linux
>>
>> There are some safeguard image-side but it would be great if someone
>> could check that vm side.
>>
>
> That seems wrong indeed, since BitBlt can only handle power-of-two depths
> currently. It should answer 32 or -32 in this case.
>
> Actually ... is there a difference in pixel layout for 32 bit MSB vs LSB
> forms? A quick test in SqueakJS suggests there isn’t.
>
>
> I do not get what you mean by 32 bits MSB vs LSB form. Could you give an
> example of what to test?
> If you mean a difference between depth 32 or -32, I do not see any
> difference.
>

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')

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.squeakfoundation.org/pipermail/vm-dev/attachments/20170202/6c29fedf/attachment.html>