[haiku-development] Re: ShowImage patch
- From: Christian Packmann <Christian.Packmann@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 04 Mar 2009 11:53:57 +0100
Stephan Aßmus schrieb:
Christian Packmann schrieb:
I've looked at the ShowImage zoom routines, and a clean implementation
of better zooming isn't as easy as it seemed at first glance. Not that
hard, but I don't have the time for it right now. I'll look into this
later, but probably only after I implemented a SSE2 version of the
ScaleBilinear function, which is far too unrealtime for my taste.
Before you do that, please have a look at the bilinear scaling routine
in src/servers/app/drawing/Painter/Painter.cpp. Accelerate that one
instead. I think the inner loop of that routine is as fast as it gets
with C++, unless I am missing a nice trick.
Excellent code, my compliments. I don't think any significant speedup can
be done in integer code.
> And if you can accelerate
that, make ShowImage use the filter option when drawing bitmaps (there
is a new BView::DrawBitmap() version in Haiku that takes more options).
This work will benefit MediaPlayer as well then. Thanks a lot!
I agree that Painters code is more important; but ShowImage uses threading
for its scaling, which will be useful for extreme magnifications. But the
optimizations from Painters code could be backported to ShowImage and its
threaded model, so no big loss there. Actually the code in Painter is
better and could give much higher speedups when SSE2-optimized.
We'll need to discuss some implementation details, though. I see that you
use 16-bit values for the intermediate values. This /might/ enable the
processing of 2 pixels per loop iteration (SSE registers have 128 bit or
8x16 bit, enough for 2 pixels - and we could process alpha "for free").
I'll have to check the docs if SSE2 supports all the needed instructions,
but this should be doable. Anyway, this will require a rewrite of the
loops, which are currently hard-coded to process one pixel at a time; I'd
like to discuss this with you, as you probably have the best knowledge
about the runtime behavior and what would work well, what not.
I'd prefer to discuss this on haiku-optimize, but we can also do it here
if you prefer.
[List of proposed interface changes]
All these sound perfect. Except maybe I would like to toss the idea to
have Alt-Left/Right rotate the image.
Good idea IMO. We could move multi-image navigation to all Shift+Alt+Cursor.
But I'd leave Alt+R, Alt+Shift+R as default rotate shortcuts and add the
Alt-Left/Right as "invisible" shortcuts, documented in the users guide.
> Ideally, we'd have an icon tool
bar for the hidden features to be less hidden... :-)
My own personal preference: no - just RTFM.
But I agree this would be useful for "normal" users. As long as it can be
turned off. Eh, but just to make it clear: I won't implement this. :-)
Do we have any toolbar class yet, anyway? If not, we should wait until one
is standard in the OS; "manually" implementing such features in single
applications would be stupid IMO. Waste of code and time.
Christian
Other related posts:
