[Gambas-user] jpeg performance

[Benoit Minisini]

On Tuesday 03 January 2006 20:55, Rob Kudla wrote:
> On Tue January 3 2006 14:02, nando wrote:
> > Shelling to a 3-line Shell script (a different one for each
> > camera):
>
> You might also consider using "convert" or some other ImageMagick
> tool run from a shell without a WAIT to do the stretching, so
> that 4 of those can be done at the same time too.  It won't be
> any faster than Qt's stretching, but at least your program isn't
> frozen while it's happening.
>
> Also, using a drawing area is slower than using two picture boxes
> for each image and showing/hiding them (basically page flipping)
> in my experience.  

Cached drawing area or not?

> I wrote an app to capture and display frames 
> from a security camera (by shelling out to some v4l capture
> utility), and I used that approach.  Qt is still slow enough
> that when you make the picture full-screen you can see the
> redraw, but short of redoing it as an SDL app I don't see any
> other option.

Maybe you could use the gb.v4l component of Daniel?

First, by default, stretching is antialiazed. By passing FALSE as third 
argument of Stretch, things will be quicker.

Anyway, stretching is slow, especially to half the size of the desktop. It is 
written in pure C, and does not use any MMX/SSE x86 instruction.

A good idea would be integrating the stretch feature inside the X server. It 
would be faster: you will send only the initial image to the X server, not 
the result of the stretching, that may be very big.

>
> When gb.qt.opengl is mature, you might look into that for faster
> scaling as well.

Maybe you can already use it for that - I don't know, Laurent Carlier will 
tell about that.

Regards,

-- 
Benoit Minisini