gui-image-dynamic-range

[Zack Rusin]

On Sunday, March 18, 2012 04:47:56 PM José Fonseca wrote:
> Yeah. It's currently pretty hard to diagnose depth buffer related
> issues, with or without gui, as everything gets funneled into rgba8
> images.
> 
> I don't know a good library that would fit our needs neither. My
> current idea is to promote the Image class to a template thhat has the
> channel type as parameter:
> 
>    template< class ChanType , unsigned numChannels >
>    class Image;
> 
> and then add few virtual methods for the operations we care:
>  - (de)serialize
>   - produce a RGBA8 , with adjustable range
> 
> I think this should be relatively simple.

That sounds good.

> Another other issue is how to encode this on JSON. On commit aa0a7822
> you said that PNG was a performance win because it reduced the
> pressure on JSON parser. 

Yea, it was a huge win. I never profiled qtjson so I'm not sure how it 
actually parsed the json documents but Qt 5 has a json parser built in that 
iirc is in the range of 10x faster (http://doc.qt.nokia.com/5.0-
snapshot/qjsondocument.html). While we can't depend on Qt5, I could probably 
just take the h/cpp files and use them directly in the source if required.

> So either we use some compression (snappy,
> zlib) when serializing the above images into JSON, or we drop JSON and
> use trace binary format everywhere including state dumps.

I'd probably try to avoid the compression in that case. I did try generic zlib 
compression first but the issue was that without dedicated image compression 
support, binary data doesn't compress that well. With png's it was an order of 
magnitude, while zlib was up to 100%. A decent json parser would probably 
perform well enough on that uncompressed data. Binary format would likely be 
ideal for performance, but it might not be useful for others, if any, third 
party tools that could be built upon the apitrace tools.

z