[haiku-commits] Re: r37017 - in haiku/trunk: build/jam src/apps/screenshot

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Mon, 07 Jun 2010 13:33:18 +0200

On 2010-06-07 at 12:10:05 [+0200], Michael Pfeiffer 
<michael.w.pfeiffer@xxxxxxxxx> wrote:
> 
> Am 07.06.2010 um 11:39 schrieb Stephan Assmus:
> 
> > 
> > On 2010-06-07 at 10:01:38 [+0200], Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
> > wrote:
> >> Stephan Assmus <superstippi@xxxxxx> wrote:
> >>> On 2010-06-06 at 18:01:52 [+0200], Humdinger <humdingerb@xxxxxxxxxxxxxx>
> >>> The filtering comes for free when passing B_FILTER_BITMAP_BILINEAR as
> >>> additional options argument to DrawBitmap().
> 
> Is this fast enough?

IIRC the implementation in ShowImage is pretty slow. The app_server 
implementation is already very fast as the C code version, but Christian 
Packman was so kind and provided an SIMD optimized version which is much 
faster yet. Both the ShowImage agorithm and the app_server version probably 
depend on the output image size, but for my 1920x1200 monitor, a 1.8 GHz Core 
2 Duo is fast enough for 25 fps. Don't know if downscaling would be slower 
than upscaling. For bilinear scaling, the considered input pixels are never 
more than four times more the output pixels, though. So it's independent of 
the original image size in that way (I think we can safely ignore RAM speed 
nowadays).

> >>> For downscaling, there
> >>> are
> >>> better algorithms, bilinear scaling only looks good at a factor above
> >>> 0.5.
> >>> But it's a start.
> >> 
> >> That also means that we can remove the bilinear code from ShowImage,
> >> right?
> 
> In ShowImage the filter runs in a background thread. On slow hardware it
> could take several seconds (IIRC).

During video playback, more stuff happens than when just displaying an image 
in ShowImage. So even on hardware which is 25 times slower than my 1.8 GHz 
Core 2 Duo, the delay should be below a second.

> I am also in favor of removing duplicated code, as long as ShowImage stays 
> responsive.

I am relatively confident it will be more responsive than now, but we have 
version history to come to our rescue. :-)

Best regards,
-Stephan

Other related posts: