Fog: A High-Performance Alternative To Cairo

[phoronix]

Phoronix: Fog: A High-Performance Alternative To Cairo

While Cairo gets much of the spotlight when it comes to a 2D vector graphics drawing library, there's another open-source project that claims to provide even faster performance and greater benefits; meet the Fog-Framework...

http://www.phoronix.com/vr.php?view=MTA2NTc

[cl333r]

I think Mozilla's work will be more valuable since it's gonna be hw accelerated from the get go with both GL & DX in mind.

[halo9en]

Their benchmark results show impressive numbers.

[sireangelus]

sigh.. can someone explain to me why they are comparing the gdi+ performance instead of direct2d??

[ickle]

FogBench - Fog-Framework performance suite (version 0.4)

Surface  : 640x480
Quantity : 10000

Processor: Intel(R) Core(TM) i7 CPU L [email protected]
Features1: MMX=yes, MMXExt=yes, 3dNow=no, 3dNowExt=no
Features2: SSE=yes, SSE2=yes, SSE3=yes, SSSE3=yes SSE4.1=yes, SSE4.2=yes
Features3: AVX=no
CPU Count: 4

Fog::PngLibrary::init() - Can't load symbol 'png_set_longjmp_fn'.
Fog (st)              |    8x8|  16x16|  32x32|  64x64|128x128|
----------------------+-------+-------+-------+-------+-------+
Create/Destroy        |                                     20|
FillRectI-Solid-Copy  |      2|      4|      8|     23|     73|
FillRectI-Solid-Over  |      4|     11|     39|    148|    570|
FillRectI-LinGr-Copy  |     62|     69|     93|    184|    537|
FillRectI-LinGr-Over  |     66|     82|    140|    372|   1279|
FillRectF-Solid-Copy  |      9|     17|     36|     98|    310|
FillRectF-Solid-Over  |     10|     20|     52|    158|    546|
FillRectF-LinGr-Copy  |     73|     91|    141|    305|    899|
FillRectF-LinGr-Over  |     75|     98|    173|    434|   1402|
FillRectRot-Solid-Copy|     26|     39|     69|    151|    401|
FillRectRot-Solid-Over|     27|     43|     84|    210|    636|
FillRectRot-LinGr-Copy|     95|    118|    180|    366|    998|
FillRectRot-LinGr-Over|     96|    125|    208|    481|   1477|
FillRound-Solid-Copy  |     29|     45|     88|    158|    388|
FillRound-Solid-Over  |     30|     49|     94|    211|    610|
FillRound-LinGr-Copy  |     96|    122|    184|    354|    953|
FillRound-LinGr-Over  |     98|    128|    209|    460|   1417|
FillPolygon-Solid-Copy|     39|     69|    135|    285|    644|
FillPolygon-Solid-Over|     40|     72|    146|    332|    833|
FillPolygon-LinGr-Copy|    107|    149|    254|    522|   1262|
FillPolygon-LinGr-Over|    110|    153|    271|    606|   1628|
FillComplex-Solid-Copy|    266|    449|    866|   1934|   4738|
FillComplex-Solid-Over|    268|    456|    891|   2029|   5121|
FillComplex-LinGr-Copy|    340|    550|   1059|   2468|   6552|
FillComplex-LinGr-Over|    343|    558|   1089|   2584|   7143|
BlitImageI-Copy       |      0|      0|      0|      0|      0|
BlitImageI-Over       |      0|      0|      0|      0|      0|
BlitImageF-Copy       |      0|      0|      0|      0|      0|
BlitImageF-Over       |      0|      0|      0|      0|      0|
BlitImageRot-Copy     |      3|      3|      3|      3|      3|
BlitImageRot-Over     |      3|      3|      3|      3|      3|
----------------------+-------+-------+-------+-------+-------+
Total                 |   2330|   3536|   6529|  14892|  40438|

Cairo                 |    8x8|  16x16|  32x32|  64x64|128x128|
----------------------+-------+-------+-------+-------+-------+
Create/Destroy        |                                      1|
FillRectI-Solid-Copy  |      7|      8|      8|     11|     20|
FillRectI-Solid-Over  |     10|     12|     15|     26|     55|
FillRectI-LinGr-Copy  |     25|     35|     64|    177|    590|
FillRectI-LinGr-Over  |     26|     36|     69|    190|    640|
FillRectF-Solid-Copy  |      7|      8|      9|     11|     21|
FillRectF-Solid-Over  |     12|     12|     16|     25|     56|
FillRectF-LinGr-Copy  |     27|     37|     68|    181|    600|
FillRectF-LinGr-Over  |     28|     39|     73|    194|    652|
FillRectRot-Solid-Copy|     21|     24|     29|     44|     90|
FillRectRot-Solid-Over|     28|     34|     49|     80|    173|
FillRectRot-LinGr-Copy|    107|    131|    196|    409|   1175|
FillRectRot-LinGr-Over|     55|     74|    126|    296|    924|
FillRound-Solid-Copy  |     37|     49|     63|     89|    130|
FillRound-Solid-Over  |     43|     58|     77|    116|    194|
FillRound-LinGr-Copy  |    135|    173|    237|    421|   1014|
FillRound-LinGr-Over  |     62|     86|    135|    282|    795|
FillPolygon-Solid-Copy|     34|     40|     53|     80|    143|
FillPolygon-Solid-Over|     42|     53|     79|    130|    254|
FillPolygon-LinGr-Copy|    128|    160|    247|    515|   1421|
FillPolygon-LinGr-Over|     63|     89|    159|    351|   1047|
FillComplex-Solid-Copy|    222|    287|    397|    598|   1008|
FillComplex-Solid-Over|    231|    300|    431|    678|   1254|
FillComplex-LinGr-Copy|    388|    493|    741|   1422|   3554|
FillComplex-LinGr-Over|    260|    358|    573|   1124|   2862|
BlitImageI-Copy       |      7|      8|     10|     18|     51|
BlitImageI-Over       |      4|      4|      4|      4|      4|
BlitImageF-Copy       |      8|      9|     10|     19|     52|
BlitImageF-Over       |      4|      4|      4|      4|      4|
BlitImageRot-Copy     |     22|     28|     43|     87|    245|
BlitImageRot-Over     |      5|      5|      5|      5|      5|
----------------------+-------+-------+-------+-------+-------+
Total                 |   2064|   2667|   4002|   7602|  19048|

The multi-threaded capablities have been long desired, but improvements to cairo-image pale in significance to enabling GPU acceleration. However, judging from those results there are a few areas where we can easily improve cairo, but overall it appears cairo is in relatively good shape.

[benjamin545]

and why is it we cannot just go to using straight openvg? it sure seems wasteful to keep coming up with 2d vector graphics replacements for cario when in the end they will all just be wrappers around a way to accelerate them with the gpu. (openvg, opengl, gallium3d)

[bug77]

...the Fog-Framework engine is multi-threaded...

Is it? Afaik, no graphics framework in multithreaded since generic thread safety incurs too much a performance penalty. "Multithreaded" in the context of graphics frameworks usually means that it supports (and in some places requires) the use of multiple threads.
Nitpicking aside, good for them!

[elanthis]

Is it? Afaik, no graphics framework in multithreaded since generic thread safety incurs too much a performance penalty. "Multithreaded" in the context of graphics frameworks usually means that it supports (and in some places requires) the use of multiple threads.
Nitpicking aside, good for them!

If you have any real sense of how to do proper high performance multithreading, there usually isn't much thread safety overhead. Larger batches distributed to a task-based thread-pool in a "shared nothing" architecture works really well. If done right it requires no synchronization primitives of any kind besides the task management bits (which only incur overhead on a thread when they're not processing a task). That is, after all, exactly what a GPU does.

A lot of people got into threading with Java, which teaches you to thread _everything_ and then synchronize the hell out of every data structure. That's awful, and wrong. If you're looking to reduce latency for event handling (e.g., handling network sockets), then use an event-based API. If you're looking to utilize all cores in today's multicore CPUs, then don't do something as silly as adding a ton of chokepoints and potential deadlocks to your code.

In the case of a 2D/3D renderer, there are many opportunities for threading. Path tessellation, region tessellation, gradient generation, programmable shaders, blitting large buffers, color conversion and blending... all of these are data-intensive operations that can easily be broken into separate independent chunks, farmed out to a number of threads, and the results processed with little to no extra work. The operation that's blending the pixel at (20,35) is not dependent on the operation blending the pixel at (10,23), after all. They can both be done in parallel, with absolutely no need to add any locking or atomic synchronization operations. The only thing to be careful of is the memory architecture of the host system (where cache line boundaries are, and which addresses in memory can be safely modified on different hardware threads without contention or data races; this is all well-documented and very easy to deal with, though).