Comment 1 Pierre Ossman 2014-04-24 12:27:46 CEST

Need to have another look at the depth conversion. Neither bit replication, nor truncation gives the optimal value. Only truncation is causing any significant error though.

Might want to consider bug 3893 at the same time as the method chosen for dithering could influence the error when downsampling.

Comment 2 Pierre Ossman 2014-07-04 16:24:19 CEST

The new code is significantly slower for 565 formats compared to the old PixelTransformer. Need to have a look to see if we can improve that case.


(rgbFromBuffer is also suspiciously slow in all cases, but that's not a regression)

Comment 3 Pierre Ossman 2014-07-14 16:26:03 CEST

Finally merged upstream.

Tester should focus on torturing pixel conversions. So try as many different format mismatches as possible between the client and server. Also remember to test endian mismatches.

The tester should also test every available codec.

Comment 4 Pierre Ossman 2014-09-24 15:01:41 CEST

I'm seeing endian conversion bugs when I tested the armv7el client against solaris.

Comment 5 Pierre Ossman 2014-09-24 16:07:09 CEST

Happens on my Fedora machine as well, and with older clients. So this is a server side problem. Which isn't terribly surprising as we normally let the server convert to what the client wants.

Comment 6 Pierre Ossman 2014-09-25 15:13:48 CEST

Fixed in r29422.

Comment 7 Henrik Andersson 2014-10-08 16:04:37 CEST

32 bit vncviewer displays garbage and segfaults when running on 16bit desktop connecting to 24bpp server. Produced on Igel terminal.

Comment 8 Henrik Andersson 2014-10-08 16:04:50 CEST

32 bit vncviewer displays garbage and segfaults when running on 16bit desktop connecting to 24bpp server. Produced on Igel terminal.

Comment 9 Pierre Ossman 2014-10-09 14:56:24 CEST

Only happens when JPEG compression is used.

Comment 10 Pierre Ossman 2014-10-09 17:04:23 CEST

Fixed in r29484.

Comment 11 Henrik Andersson 2014-10-10 15:17:52 CEST

(In reply to comment #10)
> Fixed in r29484.

Verified working on Igel with 16bpp.

Comment 12 Henrik Andersson 2014-10-13 10:29:32 CEST

Tested 16bit and 32bit client little endian, each client side depths;

8bpp (rgb111), 8bpp (rgb222),
8bpp (rgb332), 16bpp (rgb565),
24bpp (rgb888)

against a little endian server running with depths;

32bpp (rgb888), 6bpp (rgb565)

Everything works as expected, except that it was a bit laggy while testing rgb888 -> rgb565 conversion on the Igel client.

During the tests i also tested different encoding algorithms with and without jpeg compression.

Comment 13 Henrik Andersson 2014-10-13 11:10:38 CEST

(In reply to comment #12)
> Tested 16bit and 32bit client little endian, each client side depths;
> 
> 8bpp (rgb111), 8bpp (rgb222),
> 8bpp (rgb332), 16bpp (rgb565),
> 24bpp (rgb888)
> 
> against a little endian server running with depths;
> 
> 32bpp (rgb888), 6bpp (rgb565)
> 
> Everything works as expected, except that it was a bit laggy while testing
> rgb888 -> rgb565 conversion on the Igel client.
> 
> During the tests i also tested different encoding algorithms with and without
> jpeg compression.

Same tests as above has been performed using a combination of little endian and big endian, both server and client side.

Works as expected.