gui-image-dynamic-range

[José Fonseca]

On Sun, Mar 25, 2012 at 6:15 PM, Zack Rusin <zack at kde.org> wrote:
> 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.

That would be nice.I just happened to look at QJSON code, and it
abuses QIODevice::peeks instead of maintaining a lookhead character,
which is very innefficient.

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

Ok. Sounds good.

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

We could use binary on the gui, and retain JSON for 3rd parties. For
example, I recently added an option to dump traces in Python pickle's
format, which is really fast.

Interestingly, the Qt documention link you referred above mentions a
binary format too.

But I'm happy to try uncompressed JSON on the new parse first an see
how it goes.

Jose