Re: [gtk-vnc-devel] Fix endianness handling and BGR pixel formats

[Anthony Liguori <anthony codemonkey ws>]

Yeah, this looks like an obvious fix.  I'm not 100% sure why it wasn't
like this in the first place.  Good catch!

I'm not a huge fan of the __BYTE_ORDER == __LITTLE_ENDIAN stuff as it's
a compile time thing but it's not a make or break thing for me.

Regards,

Anthony Liguori

On Wed, 2007-08-22 at 17:17 +0100, Daniel P. Berrange wrote:
> As previously mentioned a few weeks back the BGR pixel format handling is
> wrong because we're getting the shifts wrong. In fact we're adjusting for
> the difference between local & remote shifts twice and getting it wrong
> for the mis-matched case. The adjustment in gvnc_set_local  was just not
> needed at all. Since the blk functions are already doing shifts I simply
> moved the application of the local shift into the blt code & it 'just works'
> for both BGR and RGB pixels.
> 
> Next up, we're not checking for endianness differences between client and
> server. In the case of a difference, we need to reverse the shifts. eg so
> a  shift of  R:16, G:8, B:0, becomes R:0, G:8, B:16. This is done by simply
> subtracting the server specified shift from the bits_per_pixel, with the
> minor complication of having to also take account of possible padding (eg
> the BPP=32, depth=24 case).
> 
> With the attached patch we work correctly with RGB, BGR, and mixed endian.
> It is considerably nicer than my previous patch for BGR.
> 
> Regards,
> Dan.
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________ Gtk-vnc-devel mailing list Gtk-vnc-devel lists sourceforge net https://lists.sourceforge.net/lists/listinfo/gtk-vnc-devel