Bugzilla – Bug 5026
finish TigerVNC cleanup
Last modified: 2014-10-13 11:10:38
You need to
before you can comment on or make changes to this bug.
There wasn't enough time to finish bug 4915 and get everything committed. So we
need this bug to finish the work done there.
Need to have another look at the depth conversion. Neither bit replication, nor
truncation gives the optimal value. Only truncation is causing any significant
Might want to consider bug 3893 at the same time as the method chosen for
dithering could influence the error when downsampling.
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
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.
I'm seeing endian conversion bugs when I tested the armv7el client against
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.
Fixed in r29422.
32 bit vncviewer displays garbage and segfaults when running on 16bit desktop
connecting to 24bpp server. Produced on Igel terminal.
Only happens when JPEG compression is used.
Fixed in r29484.
(In reply to comment #10)
> Fixed in r29484.
Verified working on Igel with 16bpp.
Tested 16bit and 32bit client little endian, each client side depths;
8bpp (rgb111), 8bpp (rgb222),
8bpp (rgb332), 16bpp (rgb565),
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
(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.