BltMaskBitMapRastPort() speed effected by mask contents

	Bottom Previous Topic Next Topic
Register To Post

(1) 2 »

ChrisH

Posted on: 2012/3/11 15:48 #1

Home away from home

I've noticed that the speed of BltMaskBitMapRastPort() seems to depend on whether the mask has much transparent or opaque areas visible. This seems to imply the CPU is doing work that the graphics card should be doing

I'm assuming that the problem is how I'm allocating the mask bitmap. Can anyone tell me how I *should* be allocating the mask? At the moment I'm using AllocRaster() to allocate bitmap->plane[0], where the width & height are the same as the corresponding (main) bitmap.

I suppose it might be how I'm allocating the main bitmap. I'm using AllocBitMap() with BMF_DISPLAYABLE and BMF_MINPLANES, and made a friend with the window's bitmap.

Author of the PortablE programming language.

broadblues

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/11 16:11 #2

Home away from home

Quote:

I've noticed that the speed of BltMaskBitMapRastPort() seems to depend on whether the mask has much transparent or opaque areas visible. This seems to imply the CPU is doing work that the graphics card should be doing

Does it? By what logic?

Whichever is used to do the blit, copying data will always take longer than not copying data so I'd expect a difference whether GPU or CPU. (maybe I would be expecting wrong though

)

I'm not sure about allocating the mask (the only examples I've got to hand are old bits of AWeb code which whilst they work may not be using best practice modern practice, they use AllocVec to allocate the mask)

But you should be allocating the bitmap as a friend bit map so that sounds right to me.

Blender For OS4.x : Blues : Walker Broad

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/11 16:17 #3

Home away from home

Quote:

Does it? By what logic?

Because the gfx card has very fast access to video memory, where-as the CPU has very slow access.

Quote:

Whichever is used to do the blit, copying data will always take longer than not copying data

Yes, but you won't notice the speed difference when the graphics card is doing it (because it is so fast anyway).

Author of the PortablE programming language.

broadblues

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/11 16:20 #4

Home away from home

Quote:

Yes, but you won't notice the speed difference when the graphics card is doing it (because it is so fast anyway).

I'm not convinced

Also consider that the bitmask might need converting to a format that the GPU can use and that might give the change in performance.

Have you considered usin BltBitmapTags it has alot more options for dealing masking and transparency than the old blitmask#? functions

Blender For OS4.x : Blues : Walker Broad

LiveForIt

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/11 19:18 #5

Home away from home

Screen bitmap uses graphics native format I have noticed.

The graphic card uses little endian format while Amiga uses big endian format, the graphic has to be always converted before it’s copied.

16BIT R5G6B5

From: | R5 + G3 | G3 + B5 | to: | G3 + B5 | R5 + G3 |

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

Hans

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/11 20:59 #6

Home away from home

Quote:

ChrisH wrote:
I've noticed that the speed of BltMaskBitMapRastPort() seems to depend on whether the mask has much transparent or opaque areas visible. This seems to imply the CPU is doing work that the graphics card should be doing

BltMaskBitMapRastPort() is indeed software rendered. I suggest that you replace the mask with an alpha bitmap, and use CompositeTags().

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/12 11:46 #7

Home away from home

@Hans
Thanks for the explanation. It's a shame that BltMaskBitMapRastPort() doesn't (or can't?) have it's common case optimised to use the graphics card.

Author of the PortablE programming language.

Chris

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/12 18:11 #8

Amigans Defender

@ChrisH

Even BltBitMapTags with an alpha mask is not hardware accelerated, you have to use CompositeTags for that.

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/13 9:49 #9

Home away from home

OK, I've (finally) looked into CompositeTagList(), and it seems relatively easy to use. The requirement for the 'mask' to be the alpha-channel in a bitmap seems to be why OS4 can't use CompositeTagList() to h/w accelerate BltMaskBitMapRastPort()...

... but I'm puzzled as to why CompositeTagList() isn't used to h/w accelerate BitMapScale(). At first glance it would appear trivial! (I'm going to have a go at doing that now.)

Author of the PortablE programming language.

Chris

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/13 10:28 #10

Amigans Defender

Quote:

ChrisH wrote:
... but I'm puzzled as to why CompositeTagList() isn't used to h/w accelerate BitMapScale(). At first glance it would appear trivial! (I'm going to have a go at doing that now.)

It is trivial, and gives a massive speed boost. Same for BltBitMapTags with SrcAlpha. It seems a little ridiculous that these don't automatically use CompositeTags when available.

As a result I have to do something like:
if gfx.lib >= 53 then compositetags else bitmapscale

which seems a little extraneous to requirements.

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/13 11:21 #11

Home away from home

@Chris
I've written a simple wrapper (UNFINISHED - DO NOT USE!) for PortablE, but I have found that OFTEN (not always) the results are horizontally off-set by 1 pixel compared to the real BitMapScale():


PROC bitMapScale(bitScaleArgs:PTR TO bitscaleargs)

    DEF result

    result := CompositeTagList(COMPOSITE_SRC, bitScaleArgs.srcbitmap, bitScaleArgs.destbitmap, [

        COMPTAG_SRCX,      bitScaleArgs.srcx,

        COMPTAG_SRCY,      bitScaleArgs.srcy,

        COMPTAG_SRCWIDTH,  bitScaleArgs.srcwidth,

        COMPTAG_SRCHEIGHT, bitScaleArgs.srcheight,

        COMPTAG_DESTX,     bitScaleArgs.destx,

        COMPTAG_DESTY,     bitScaleArgs.desty,

        COMPTAG_DESTWIDTH, bitScaleArgs.destwidth,

        COMPTAG_DESTHEIGHT,bitScaleArgs.destheight,

        COMPTAG_OFFSETX,   bitScaleArgs.destx,

        COMPTAG_OFFSETY,   bitScaleArgs.desty,

        COMPTAG_SCALEX, bitScaleArgs.xdestfactor * COMP_FIX_ONE / bitScaleArgs.xsrcfactor,

        COMPTAG_SCALEY, bitScaleArgs.ydestfactor * COMP_FIX_ONE / bitScaleArgs.ysrcfactor,

OAT / bitScaleArgs.ysrcfactor),

        COMPTAG_FLAGS,COMPFLAG_IGNOREDESTALPHA,

    TAG_END]:tagitem)

    IF result <> COMPERR_SUCCESS THEN Throw("BUG", 'pAmigaGraphics; bitMapScale(); CompositeTagList() failed')

ENDPROC

The reason I can tell it is offset, is that I am scaling the bitmap using this (CompositeTagList) but the mask using the real BitMapScale (because CompositeTagList doesn't like scaling masks), and sometimes the masked area shows on one edge.

I am scaling by exactly *2, so differences in the scaling algorithm should not be an issue.

And even forcing the software implementation of CompositeTagList makes no difference! (Although as I am currently scaling non-displayable bitmaps, it would probably be using software anyway.)

Do you have any suggestions?

As an aside, I need to add a fall-back for when CompositeTagList() fails (say due to incompatible bitmap formats, e.g. when scaling masks).

Author of the PortablE programming language.

Chris

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/13 12:07 #12

Amigans Defender

@ChrisH

I would guess it's a rounding error resulting from the calculation you are passing in COMPTAG_SCALEX, COMPTAG_SCALEY.

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/13 12:10 #13

Home away from home

@Chris
COMPTAG_SCALEX & Y receive exactly 0x20000, and thus should scale exactly by *2 (as mentioned earlier).

BTW, I can "work around" the differences with BitMapScale() by getting CompositeTagList() to scale the masks as well, but that requires copying them to Video memory (which isn't super fast IIRC) and then copying the scaled result back from Video memory (which is horrendously slow). So this isn't a real solution :( .

Unless I can find a real fix, it is not possible to reliably emulate BitMapScale() using CompositeTagList(). Which may be why OS4 devs haven't already done it.

Author of the PortablE programming language.

Hans

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/13 19:50 #14

Home away from home

Quote:

ChrisH wrote:
@Chris
BTW, I can "work around" the differences with BitMapScale() by getting CompositeTagList() to scale the masks as well, but that requires copying them to Video memory (which isn't super fast IIRC) and then copying the scaled result back from Video memory (which is horrendously slow). So this isn't a real solution :( .

I don't understand what you're trying to do. CompositeTags() can use an alpha mask that is the same size as the source bitmap (i.e., the source alpha mask, as opposed to the destination alpha mask), so why are you rescaling the alpha mask? Also, why do you need to copy the scaled alpha mask back to main memory? That implies that you're doing more software rendering.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/14 9:27 #15

Home away from home

@Hans
I was simply trying to emulate BitMapScale(), rather than rewrite my program to use an (8-bit) Alpha channel instead a 1-bit mask! (That kind of rewrite was supposed to come later, after I got more comfortable with CompositeTagList().)

As far as I can tell, 1-bit masks must be stored in non-video ram, because otherwise the result of BltMaskBitMapRastPort() tends to be garbage. (This makes some kind of sense when the CPU is doing the masking.)

BTW, do you know if CompositeTagList()'s COMPTAG_SrcAlphaMask tag will accept an 8-bit bitmap (as a valid Alpha channel), rather than requiring a whole 32-bit bitmap (where 24-bits will be ignored)? (That would greatly simplify my switch from 1-bit masks to 8-bit alpha channels.)

Author of the PortablE programming language.

salass00

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/14 10:59 #16

Just can't stay away

Quote:

BTW, do you know if CompositeTagList()'s COMPTAG_SrcAlphaMask tag will accept an 8-bit bitmap (as a valid Alpha channel), rather than requiring a whole 32-bit bitmap (where 24-bits will be ignored)? (That would greatly simplify my switch from 1-bit masks to 8-bit alpha channels.)

If the bitmap has pixel format RGBFB_ALPHA8 then I would assume that it does.

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/18 13:22 #17

Home away from home

@Chris Quote:

As a result I have to do something like:
if gfx.lib >= 53 then compositetags else bitmapscale

Thanks for the idea. With E I should be able to do something like "gfxbase.version >= 53".

Edited by ChrisH on 2012/3/20 10:51:19

Author of the PortablE programming language.

Chris

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/18 14:04 #18

Amigans Defender

Yes. The proper comparison in C is:
if(GfxBase->LibNode.lib_Version >= 53) CompositeTags();
else BitMapScale();

Hans

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/18 19:49 #19

Home away from home

Quote:

salass00 wrote:
Quote:

BTW, do you know if CompositeTagList()'s COMPTAG_SrcAlphaMask tag will accept an 8-bit bitmap (as a valid Alpha channel), rather than requiring a whole 32-bit bitmap (where 24-bits will be ignored)? (That would greatly simplify my switch from 1-bit masks to 8-bit alpha channels.)

If the bitmap has pixel format RGBFB_ALPHA8 then I would assume that it does.

RGBFB_CLUT should work too, but RGBFB_ALPHA8 is the correct pixel format for alpha masks.

Hans

Join Kea Campus' Amiga Corner and support Amiga content creation
https://keasigmadelta.com/ - see more of my work

ChrisH

Re: BltMaskBitMapRastPort() speed effected by mask contents

Posted on: 2012/3/19 9:08 #20

Home away from home

@Hans & salass00
Thanks for the info... but in the end, for the sake of compatibility with uh "other OSes", I've decided to keep the alpha channel as part of the bitmap. I guess it might be slightly faster as well!

Author of the PortablE programming language.

Register To Post	(1) 2 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 3 ( 0 members and 3 Anonymous Users )