Quantcast

pb with primitive #primitiveScreenDepth on Linux ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

pb with primitive #primitiveScreenDepth on Linux ?

demarey
 
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.

Christophe.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: pb with primitive #primitiveScreenDepth on Linux ?

Bert Freudenberg
 
On Tue, Jan 31, 2017 at 10:44 AM, Christophe Demarey <[hidden email]> 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.

- Bert - 
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: pb with primitive #primitiveScreenDepth on Linux ?

demarey
 
Hello Bert,

Le 31 janv. 2017 à 18:18, Bert Freudenberg <[hidden email]> a écrit :

On Tue, Jan 31, 2017 at 10:44 AM, Christophe Demarey <[hidden email]> 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.

Christophe

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: pb with primitive #primitiveScreenDepth on Linux ?

Bert Freudenberg
 
On Thu, Feb 2, 2017 at 10:44 AM, Christophe Demarey <[hidden email]> wrote:
 
Hello Bert,

Le 31 janv. 2017 à 18:18, Bert Freudenberg <[hidden email]> a écrit :

On Tue, Jan 31, 2017 at 10:44 AM, Christophe Demarey <[hidden email]> 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@1 depth: d) colorAt: 0@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 -
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: pb with primitive #primitiveScreenDepth on Linux ?

demarey
 

Le 2 févr. 2017 à 21:31, Bert Freudenberg <[hidden email]> 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@1 depth: d) colorAt: 0@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 -

Loading...