[haiku-development] Re: ShowImage patch

  • From: Christian Packmann <Christian.Packmann@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Wed, 04 Mar 2009 11:14:35 +0100

Ryan Leavengood schrieb:
On Mon, Mar 2, 2009 at 2:07 PM, Christian Packmann
<Christian.Packmann@xxxxxx> wrote:
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.

I too found all the zooming code a bit complicated when I was working
on it, so I know what you mean.

Yeah, this needs to be simplified. Remove the silly ZoomIn() and ZoomOut() routines, and write one general Zoom routine with Zoom(factor, bool toPosition=false, int xPos=0, int yPos=0) or somesuch. But... later.

> I didn't write the ScaleBilinear
function so don't know how much more it could be optimized, but if you
can improve it I think that would be great.

Rough guess: using SSE2 a factor of 2x on fast CPUs like a Core2, maybe 3-4x for slow CPUs like the Atom - that one should be able to profit from SSE2 code much more as it has such bad integer performance.

> By the way did you notice
that there is a deliberate pause before that function is run, to make
it quicker to move between multiple images? I mostly agree with this
choice, but at the same time the short delay before the image "clears
up" is sort of annoying when they are being slowly browsed or in a
slideshow.

I think this behavior should be changed. And IIRC this shouldn't be too hard, as the Filter routines should already support abortion of a scale-in-progress. So it should start scaling immediately, and simply abort if another picture is loaded.

However, the Filter class has problems which need to be fixed first. It leaks memory, badly. This seems to happen when zooming in and out of an image repeatedly, I guess that the temporary bitmaps aren't free correctly. I took a quick look but didn't find the problem.
This is very bad, as this will quickly KDL Haiku with:

vm_page_fault: unhandled page fault in kernel space at xxxx, ip xxxx
Thread xxx 'filter' running on CPU 1

This happens in VMWare as well as natively. I first thought it would run out of memory in the VM (768 MiB configured), but Haiku has 3.25 GiB when run natively, so a plain out-of-mem error should not occur as fast as it did.

But maybe this is also due to some bug/uncoded feature in the virt. mem manager, and not a ShowImage bug itself? Can't really judge, some comments on this would be welcome.

Christian

Other related posts: