On Dienstag, 11. Oktober 2016 19:54:30 CEST Soeren Apel wrote:
> Hi Carl-Fredrik,
> 
> > The persistence is more than just esthetics, it allows you to detect
> > spurious anomalies since the little short deviation stays on screen
> > long enough to be detected, if an oscilloscope doesn’t have
> > persistence and at the same time don’t render all frames you could
> > miss important information.
> 
> Yeah sure, though using an OpenGL output is not a requirement
> for persistence. 
> 
> > I understand the hesitation to use OPENGL or OPENGL-ES but
> > realistically what device could you think of that doesn’t have h/w
> > support for GL-Shaders that would run an oscilloscope application?
> 
> I'm thinking of Android tablets, though I don't really know how
> many are out there who lack 3D acceleration. I do however know
> that using it drains the battery more than not using it.

I am not aware of any halfway recent Android devices which are not capable of 
open OpenGL ES 2.0, most should be able to do ES 3.0.

Running a 3D benchmark at full tilt will of course drain the battery. Using 
the GPU for stuff it is meant to do will actually save energy. Current GPUs 
(even embedded) are capable of pushing several GByte/s around and doing 
calculations on this data.

> My personal dislike towards OpenGL is that I'm not aquainted with
> t (I want to learn, don't get me wrong, I just don't have the
> time to do so) and that I have the gut feeling that it'll be
> difficult to obtain pixel-perfect line output.

If you do any drawing with OpenGL 1.5 primitives you will have a hard day. If 
you use shaders, it is actually much nicer. You can just push a buffer with 
the raw sample values (i.e. an array), and a suitable shader will:

1. draw the line
2. using antialiasing
3. optionally map the trace speed to intensity
4. optionally do persistence

Now instead of pushing a full framebuffer (typically 32bit, e.g. 1920x1080 
pixels) per frame, you can push only the sample data. The framebuffer above is 
8 MByte, at 25fps this is 200MByte/s. The same amount of data equals 200 
MSample/s (@8bit). I doubt the current code is capable of drawing this amount 
of samples in realtime, but I am quite sure even a cheap tablet SoC could chew 
this data.

Kind regards,

Stefan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel

Reply via email to