Patch for cairo 1.14.10 is available at:

https://www.dropbox.com/s/2p5xyrlgyhjd ... 1.14.10-amigaos.diff?dl=1

Edit:

I just created a github repo for the cairo port:

https://github.com/salass00/cairo_lib

Pixman-1.library 53.2 is now available:

https://github.com/salass00/pixman_lib/releases

Also some progress on the AmigaOS native font backend for Cairo:

Very col. Thank you salasso

@salass00

Great work - 2 new ports! :)

Hello Salass00,

going to install pixman.
Great work!

Any news on cairo Amiga backend?

@AmigaBlitter

I just added support for tristrip rendering using CompositeTags().

This makes the "lines" program a lot quicker (about 2-4% CPU usage instead of ~15-18%) however also the lines are a bit uglier because there is no anti-aliasing (not sure how to do that with CompositeTags() or if it's possible).

@salass00

Maybe capehill can help in this, cause he used compositing for SDL2 port.

@AmigaBlitter

Compositing is used in blitting and rectangle drawing. SDL has no antialiasing features (texture filtering may be used when blitting).

@Capehill

Do you know if there's a way to use compositing to accelerate antialiasing?

@salass00 Quote:
Since drawing lines (without anti-aliasing) is so easy, IMHO it seems more likely that most of your line drawing speed-up comes from the loss of anti-aliasing?

@salass00

Hi,
any progress on the native amigaos-cairo surface?

Hello

>if there's a way to use compositing to accelerate antialiasing?
I think no

But perhaps you can draw your line in a (=bitmap) buffer (this buffered line is horizontal & dont have to be real length but says 100 pixels long ) and then draw this buffer as 2 triangles with the compositing+filtering at the correct position to destination bitmap
So copying the line with filtering will add the antialiasing

Remember to have a margin (2 pixels) around this "line" in the buffer as the filtering will "catch" pixels around the line

Note: can works too if line (pen) width is more than 1 pixels

Alain Thellier

@thellier

You mean like draw at a higher resolution and then scale down with bilinear filtering? It would be a crude and memory inefficient way to simulate anti-aliasing but it is something I've been considering.

Essentially to do anti-alias you generate a certain amount of pixels for every pixel you want to output and then use an average of their colour values.

@salass00

No need to draw at bigger resolution : you can draw your segment only one time (when you change pen width ) in a small bitmap as the filtering will "stretch" it to current line's lenght

For example a 32x32 buffer bitmap will be ok (but a bigger one will alow a bigger "pen" than 32-4=28 pixels)

A------------------------------B
--------------------------------
-----######################-----
----########################----
--###########################---
--############################--
--###P####################Q###--
--############################--
--###########################---
----#########################---
-----######################-----
--------------------------------
D------------------------------C

here we have a 9 pixels "pen" with 2 a pixels margin
We draw ABCD rectangle as 2 tris oriented/centered on PQ line

Alain

@thellier

But the compositor doesn't draw lines (that's only in the cairo high level API). The compositor should be drawing boxes, tristrips, trapetses, etc.

@salass00

Yes the compositor will only draw the buffer rectangle bitmap that contain the (cpu-maded) picture of a line

I mean it is like drawing with a "brush" in dpaint
except this brush is rotated/streched to the wanted_line pos/size

Alain

@AmigaBlitter
Quote:

It depends on what you want to achieve.

You can easily use it to achieve FSAA: just render everything into an offscreeen bitmap which is 2x2 the size than you actually need it to be, scaling all your rendering x2 accordingly.
Then render that offscreen bitmap to the screen using Compositing, scaling it down to your real desired size using filtering, done.

Apart from that, e.g. for single lines there is no way which is free of probably undesired side-effects.

E.g. thellier's approach actually fakes AA by "abusing" bilinear interpolation in combination with fully transparent bitmap areas.
While this may produce sort-of the effect you desire for short diagonal lines, it will look wrong for straight lines (then the filtering will reveal its true nature and appear as some sort of halo around your line).
And depending on your "brush's" shape it will of course have very ugly start / end points unless you take care to compensate the stretching on longer lines by increasing tesselation and only using parts of the bitmap at that areas.

However, something like this is the only way to somehow come close to what you want.
Therefore here are some ideas on how to improve it (not tried, just brainstorming ;) ):

If you want to take that route then your best bet would be to adjust the brush-bitmap and / or UV-coordinates depending on line-size and orientation.
E.g. if you want to draw a straight horizontal line then you should take care that either the brush-bitmap does not contain transparent pixels at the top / bottom or that your V-coordinate is adjusted to not scan those areas during rasterization.

Maybe you can construct an acceptable compromise via some UV-adjustment depending on the line's angle (e.g. if your transparent "border" inside the brush is 3 pixels then the y-border-offset could be something like 3*abs(cos(line_angle*2)). Then add that value to your top-V-coordinate and subtract it from your bottom-V-coordinate.

This would result in:
angle 0 (straight horizontal): 3 (which means to fully remove top/bottom transparent border)
angle 45 (diagonal) : 0 (which means full border and thus full bilinear AA fake-effect)
angle 90 (straight vertical): 3 (like 0)
and so on

Same thing for U of course.

For the start/end "caps" increasing tesselation would probably do, as being said. So instead of 2 triangles render 6, the first fixed size 2 for the line's start, then the stretched main line, then the fixed size end.

Hello

>render 6 triangles: the first fixed size 2 for the line's start, then the stretched main line, then the fixed size end.

Nice Idea


A------B----------------C------D
--------------------------------
-----######################-----
----########################----
--###########################---
--############################--
--###P####################Q###--
--############################--
--###########################---
----#########################---
-----######################-----
--------------------------------
H------G----------------F------E


Triangles:

ABG
AGH
BCF
BFG
CDE
CEF

But lines with width (pen) = 1 can still be drawn as 2 tris as the rounded extremities wont be visible

> for straight lines filtering will reveal its true nature and appear as some sort of halo around your line.

Perhaps not so much as in this case the wanted texel will be right on a true Texel position (I mean it will not interpolate a Texel at an intermediate position so blurred)

This case will need to be tested...

BTW Perhaps using Compositing will need some adjustment like adding (say) 0.5 to U V values to be in the center of the texels : need to be tested...



Alain

@salas00
Can you bring plz some notes about current state of your Cairo port ? Is it have native amigaos4 support with usage all that compositing and stuff ?

Why i ask, its because i thinking about possibility to use your version with oddyssey, so to have odyssey render youtube faster (as it currently renders through cairo which build with software rendering).

What i mean will your current version give benefits over pure software rendering in cairo ?

@kas1e

There is some h/w acceleration if you use amigaos surfaces to draw into. It is just solid coloured shapes though, and if you enable anti-alias only drawing of rectangles is h/w accelerated.

Probably much more could be done by writing a compositor using Warp3D Nova, though I haven't really looked into it yet (right now I have other projects that I want to work on).

The amigaos surfaces are created using the cairo_amigaos_surface_create() and cairo_amigaos_surface_create_from_rastport() functions (in <cairo/cairo-amigaos.h>).