plans to support more advanced viewing of textures?

[José Fonseca]

On Sat, Jan 3, 2015 at 3:06 PM, <io.github.apitrace at io7m.com> wrote:

> 'Lo.
>
> First of all, let me say: Thanks for apitrace! I'd forgotten how
> excruciating OpenGL development was before I had access to apitrace.
> Problems that used to require tons of debugging code inserted into
> renderers tend to instead get fixed with a few invocations of qapitrace
> these days.
>

Glad to hear you find it useful.


>
> Are there any plans to improve the texture viewer?


I have some ideas, but I don't know if can call a "plan".  I develop
Apitrace whenever me, one of my colleagues at VMware has an itch to
scratch, or somebody files a bug / patches and it's not too onerous to
fix/merge.  So even I have ideas I can't give an ETA.


> It seems to be
> somewhat biased towards viewing simple 8-bit r(gba) images. It seems
> like it often falls back to displaying the values of pixels in terms of
> 8-bit bytes (although curiously, it'll often display the values of
> pixels in 24-bit DEPTH_COMPONENT textures as normalized floating point
> values).


 I improved this some weeks ago -- now glretrace will try to dump textures
as floats more frequently.   But integer textures still require more work
(see https://github.com/apitrace/apitrace/issues/302 )


> It also doesn't seem to be able to handle negative values (the
> "lower" field can't be moved below 0.0.
>

Ah, yes. This is trivial to fix.


>
> Additionally, it seems as though it often fails to display RG textures
> properly, although this is a separate issue that I'll be filing a bug
> for as soon as I can come up with a minimal test case.
>

The GUI assumes one channel means Intensity (not R) and two channels means
Luminance-Alpha, not RG.  That said, I thought I had fixed this now (R/RG
textures will be dumped as RGB, with B==0, so the R and G colors don't get
reinterpreted)


Back to my "plans": my working plan for improving texture viewer is along
the following lines:
1) add support to pure integer channels to the image::Image class (in
addition to unorm8 and float32)
2) stop trying using NetPBM format for glretrace=>qapitrace, it's
hopelessly limited, and I can't find another other standard alternative
(*), so pass all information in a custom format or as separate JSON
attributes
3) make images 3 dimensional (that is, multiple faces/slices can be chosen
in the viewer via some sort of slider)
4) use a single image for all miplevels (again, mipmap level selected in
the viewer via some sort of slider)

But as I said, I can give no ETA.

Jose

(*) There's DDS and KTX file formats but both are hopelessly tied to D3D
and GL respectively, so neither is a stand-alone solution (thought the
union of both would probably cover everything.)


>
> M
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150105/7c51281c/attachment.html>