I'd like to know if someone has already made tests to compare 2D rendering performances between these 4 system on Amiga OS 4: - Use MiniGL Primitives to render 2D. - Use Cairo to render 2D - Use Intuition Blitting to render 2D - Use Composition mode.
What is the faster ? What is the "most complete" in parameters, options and capabilities ? And the average ?
Thank you.
Kindest Regards, AmiDARK
All we have to decide is what to do with the time that is given to us.
Imho Compositing + native calls will be the best and low-level as possible. With cairo you will have some layer which for sure will slow you down, and with minigl we all know what will be :)
Imho one and big point to what i say its games from amiboing: compositing + native calls => cool fps even on slow machines.
AmiDark, I agree with Kas1e. Use compositing as Thellier told you already, no ?
I tested Cairo. You can make some cools effects easily but for me the cairo methods are not finished. If I remember well, I had problems when combing differents screens, only composing mode worked, or when I used the svg, pdf format as output.
Since a lot of months without an amiga to love, I was lost. Now I feel happiness again with a Sam Flex 800 .
I'd like to know if someone has already made tests to compare 2D rendering performances between these 4 system on Amiga OS 4: - Use MiniGL Primitives to render 2D. - Use Cairo to render 2D - Use Intuition Blitting to render 2D - Use Composition mode.
You're not comparing like-for-like there. Blitting and composition will only copy BitMaps around, they won't let you draw primitives. What are you trying to achieve?
CompositeTags() is much faster than BltBitMapTags(), especially with alpha channel deployed.
MiniGL is probably the slowest, although it shouldn't be.
You missed Warp3D which ought to be quicker than MiniGL.
Cairo is pretty snappy and has more features than graphics.library when drawing primitives, but graphics.library is less fussy.
There are other third-party drawing libraries knocking about which might be better for you.
Quote:
What is the faster ?
graphics.library or Cairo along with CompositeTags() for any blits.
Quote:
What is the "most complete" in parameters, options and capabilities ?
Probably Cairo or Warp3D, but it depends what you are trying to do as to what you use. If graphics.library does what you need, it's often better to use that.
Quote:
And the average ?
graphics.library functions are always my first choice.
You also need to think about future compatibility and hardware you're trying to run on, graphics.library and compositing will always be there for all machines, warp3d and minigl being phased out as just too old to deal with modern gfx cards and not supported on some machines as you know. 3rd party libs are well... 3rd party libs, no one knows how long they'll be supported or even backwards compatible when updates are released (specially the .so nightmare). I don't know anything about cairo except it's a city in Egypt. My dodgy advice is to stick to OS4 components, avoid 3rd party stuff and keep it as simple as possible.
Amiga user since 1985 AOS4, A-EON, IBrowse & Alinea Betatester
CompositeTags() is much faster than BltBitMapTags(), especially with alpha channel deployed.
About that: Is it true, that it is not possible to scale an alpha layer (COMPTAG_SrcAlphaMask) with CompositeTags when doing a normal scaled blit? If no then why? It is really annoying to have to make a separate call to scale the ALPHA8 bitmap into another ALPHA8 bitmap for the scaling, and besides that solution doesn't work on old Radeon driver (hangs up the machine)...
CompositeTags() is much faster than BltBitMapTags(), especially with alpha channel deployed.
About that: Is it true, that it is not possible to scale an alpha layer (COMPTAG_SrcAlphaMask) with CompositeTags when doing a normal scaled blit? If no then why? It is really annoying to have to make a separate call to scale the ALPHA8 bitmap into another ALPHA8 bitmap for the scaling, and besides that solution doesn't work on old Radeon driver (hangs up the machine)...
I'm not sure what you're asking here. Do you want to use an alpha mask that is a different scale to the main source bitmap that your compositing? That is only possible when using vertex arrays with COMPVF_STW1_Present.
Why isn't it supported with simple rectangular operations? Because, normally the source alpha mask is the same size as the source bitmap. Having the alpha mask at a different scale is a weird thing to do. At some point there has to be a tradeoff between complexity and features.
I can't get COMPTAG_SrcAlphaMask to work with even ordinary blit-style operations. Unless it doesn't support BLITA_ALPHATEMPLATE-style BitMaps (in which case I'd question what sort of BitMaps it is expecting), the functionality seems to be broken or unimplemented?*
It would be very useful to be able to do hardware-accelerated BLITA_ALPHATEMPLATE blits, it's a shame CompositeTags() doesn't support these (mind you, it doesn't support RastPorts either, which causes a colour selection issue).
Perhaps we can campaign to get BltBitMapTags hardware-accelerated?
* edit ah, unless it's what Hans said about the alpha BitMap needing to be the same size. I was sort of expecting it to work aligned with the top-left of my main BitMap and didn't even consider the size. It's incredibly inconvenient, not to mention slow, to create an exact-sized BitMap, in the correct colour, for every ALPHATEMPLATE I want to blit, so that makes CompositeTags() a no-go for anti-aliased text plotting.
* edit ah, unless it's what Hans said about the alpha BitMap needing to be the same size. I was sort of expecting it to work aligned with the top-left of my main BitMap and didn't even consider the size. It's incredibly inconvenient, not to mention slow, to create an exact-sized BitMap, in the correct colour, for every ALPHATEMPLATE I want to blit, so that makes CompositeTags() a no-go for anti-aliased text plotting.
I said that it had to be the same scale. From the CompositeTags() documentation:
COMPTAG_SrcAlphaX (uint32)
COMPTAG_SrcAlphaY (uint32)
The X and Y coordinates of a subrectangle on the alpha channel
bitmap for the source. The width and height of the rectangle
are the same as the COMPTAG_SrcWidth and COMPTAG_SrcHeight.
Defaults to zero.
EDIT: I think that the documentation is wrong here about the default. The default should be the values of COMPTAG_SrcX & COMPTAG_SrcY, respectively.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
