LICE, GDI+ performance comparison

[schwa]

I was curious about the relative performance of LICE (Cockos open-source graphics library) vs GDI+ (native Windows graphics library), so I wrote a little test app to compare.

Binary: http://user.cockos.com/~schwa/files/testapp.exe
Source: http://user.cockos.com/~schwa/files/testapp.cpp
Build files: http://user.cockos.com/~schwa/files/testapp.zip
LICE: http://www.cockos.com/wdl/

The reported time is milliseconds per drawing primitive, so a smaller number means faster drawing.

i7: LICE is 5-10x faster
P4: LICE is 1.5-4x faster

http://user.cockos.com/~schwa/files/capture.gif

[nofish]

lines mode:

LICE: ~ 0.2 ms
GDI+: ~ 0.4 ms

AMD 64 X2 4600+,WinXP32 SP3, Matrox G550 dual-head (real old, direct3D acceleration not available, don't know if that matters)

[schwa]

I just updated the exe (the LICE version was previously updating the whole screen on every draw) ...

[Analogy]

LICE is 5-10x faster on my Core 2 Duo.

EDIT: The difference goes down to about 2x when I resize the window to fill my desktop.

[liteon]

a 32bit build ?

different optimization levels and architecture specific flags (if msvc has such) could affect the performance results, but also the version of the included gdi with your os and a ton of other things..


---

[Ollie]

C2D / X4500MHD IGP: / Vista32:
-----------------------------
GDI+ LICE
Lines: 0.6 0.2
Curves: 1.0 0.6
Circles: 1.0 0.3

Atom N270 / GMA950 IGP / XPH:
-----------------------------
GDI+ LICE
Lines: 1.0 0.4
Curves: 1.3 2.0
Circles: 1.6 0.6

[schwa]

different optimization levels and architecture specific flags (if msvc has such) could affect the performance results, but also the version of the included gdi with your os and a ton of other things.

Yes, absolutely. Also some graphics cards may have hardware acceleration hooks for GDI+, which can be good or bad. This is not meant to be a comprehensive test suite, just a data point.

[liteon]

i can't run it on my desktop machine (the backtrace shows a movq ss somewhere in there)

but on a vista / centrino duo laptop, lice draws 3x - 4x faster.



---

[Justin]

i can't run it on my desktop machine (the backtrace shows a movq ss somewhere in there)

but on a vista / centrino duo laptop, lice draws 3x - 4x faster.



---
What CPU is in your desktop machine?

[liteon]

What CPU is in your desktop machine?

athlon xp 1800+ (thoroughbred)
socket A(462), family: 6, model: 8, stepping: 1
sse, mmx(+ext), 3dnow(+ext)



--

[Ollie]

Another Athlon XP that doesn't work here (crash at offset 0x000019cc after launching the program).

[Justin]

Here's a build built with ICC that should a) work on older CPUs, and b) might be faster (in LICE mode) on newer CPUs too:

http://1014.org/shiz/shup/testapp.exe

-Justin

[liteon]

works now,
lice is 2x - 3x faster on this machine.



--

[Ollie]

Results (new build):


C2D / X4500MHD IGP: / Vista32:
-----------------------------
GDI+ LICE
Lines: 0.5 0.2
Curves: 0.9 0.3
Circles: 0.9 0.5

Atom N270 / GMA950 IGP / XPH:
-----------------------------
GDI+ LICE
Lines: 0.8 0.4
Curves: 1.6 0.7
Circles: 1.4 1.7

Athlon XP3200+ / GF 7600GS AGP / XPP
------------------------------------
GDI+ LICE
Lines: 0.8 0.1
Curves: 1.3 0.2
Circles: 1.3 1.6

[PitchSlap]

Here's my results with the newest build Justin posted.

Core2Duo 2Ghz, 2GB RAM, WinXP SP3
I have hardware video acceleration completely turned off, as it conflicts with my USB soundcard.

Lines
Lice: 0.17ms
GDI: 4ms

Curves
Lice 0.57
GDI: 6.8ms


Circles
Lice: 0.4ms
GDI 8.3ms

[Tranquil]

AMD Phenom II X4: / win7:
---------------------------
GDI+ LICE
Lines: 1.046 0.173
Curves: 1.458 0.650
Circles: 1.530 0.315


*this is with the second build ;)

[dub3000]

with the second build, and a largish window, lice (just used the second build) is 4-10x faster than GDI+.

i5, w7-64, 4Gb, nvidia 9600gt, most recent vid drivers

[Rome]

Just for fun: Intel Core 2 Duo T6600 2.2GHz, 4GB RAM, nVidia G 103M, Ubuntu 10.4 Lucid Lynx (Wine 1.1.42):

LICE GDI+
Lines: 4.6 ms 88.2 ms
Curves: 4.7 ms 138.0 ms
Circles: 4.7 ms 175.6 ms

Virtual Box with Windows XP on the same machine:


LICE GDI+
Lines: 2.8 ms 1.8 ms
Curves: 4.2 ms 2.0 ms
Circles: 3.3 ms 2.1 ms

Windows 7/x64 on the same machine:


LICE GDI+
Lines: 0.18 ms 2.45 ms
Curves: 0.39 ms 2.86 ms
Circles: 0.24 ms 2.74 ms

This is with the second build Justin posted above.

[Lokasenna]

And Microsoft are allowed to write their own code... why?

[Xenakios]

And Microsoft are allowed to write their own code... why?

Not everything needs super high performance. Also GDI+ apparently has a nicer API for less experienced programmers. (And there's sure plenty of those in the Windows ecosystem.) So I understand why Microsoft has done it the way they done it. And there's anyway for example DirectX for high performance graphics available, for people who can understand how to use it.

Personally I haven't seen a reason to use GDI+ for anything, it seems to indeed suck in many ways.

[schwa]

I think at the time GDI+ was created, Microsoft was hoping that a lot of GDI (very simple Microsoft drawing API, can't do antialiasing or curves) would be implemented by video card manufacturers to give "free" hardware acceleration, and that GDI+ would sort of piggyback on that. So their design spec was an easy-to-use API for programmers, and all sorts of implementation access points under the hood.

But like Xenakios said, GDI+ sort of got left behind by DirectX, which lets you do far more complex accelerated graphics, so there wasn't much incentive for graphics card manufacturers to provide acceleration for GDI+, and speed was probably never a priority for the software implementation.

There are probably a number of apps out there that have their own internal LICE-like lightweight code for drawing primitives.

[dub3000]

I think at the time GDI+ was created, Microsoft was hoping that a lot of GDI (very simple Microsoft drawing API, can't do antialiasing or curves) would be implemented by video card manufacturers to give "free" hardware acceleration, and that GDI+ would sort of piggyback on that. So their design spec was an easy-to-use API for programmers, and all sorts of implementation access points under the hood.

But like Xenakios said, GDI+ sort of got left behind by DirectX, which lets you do far more complex accelerated graphics, so there wasn't much incentive for graphics card manufacturers to provide acceleration for GDI+, and speed was probably never a priority for the software implementation.

There are probably a number of apps out there that have their own internal LICE-like lightweight code for drawing primitives.

when i first saw the speed difference, i thought it might have been because GDI+ was doing antialiasing or something (and it is) - but LICE is doing that as well.

pretty phenomenal speed difference. but GDI+ has to support weird crap like non-standard display DPIs and printing support and junk like that. still a pretty huge performance difference though.

what's the secret? :D

[JHughes]

Intel Q9550 (Core2 Quad 2.83 GHz)
ATI Radeon HD 4870 512 MB
Windows 7 x64

Lines
GDI+ = 1.05 ms
LICE = 0.19 ms
5.5X

Curves
GDI+ = 1.54 ms
LICE = 0.50 ms
3.08X

Circles
GDI+ = 1.46 ms
LICE = 0.29 ms
5.03X

[Xenakios]

Lines
Lice : 0.18ms
GDI+ : 1.24ms

Curves
Lice : 0.37ms
GDI+ : 1.6ms

Circles
Lice : 0.25ms
GDI+ : 1.7ms

(On the ICC built exe)

Windows 7/64 bit
Intel Q8200
ATI HD 3650

While the Lice results are impressive (kudos to the Cockos guys on that :) ), in perspective GDI+ isn't doing *that* bad based on these results. For example in the circle test it's still over 550 frames per second that could be drawn on my system, if I am interpreting the test correctly. Human interaction hardly requires anything more than about 30 frames per second. (Though of course GDI+ probably starts to severely suck with more complex graphics where Lice might then totally excel.)

[Tale]

These are the results on my Intel Core 2 Duo E6300 1.86 GHz / Nvidia GeForce 9500 GT:

Schwa's testapp.exe:
-----------------------------
GDI+ LICE
lines: 0.468 0.064 7.3X
curves: 0.772 0.311 2.5X
circles: 0.509 0.056 9.1X
filled circles: 0.353 0.231 1.5X

Justin's testapp.exe:
-----------------------------
GDI+ LICE
lines: 0.477 0.058 8.2X
curves: 0.770 0.237 3.2X
circles: 0.816 0.101 8.1X

[liteon]

we (http://axonlib.googlecode.com) use gdi on windows for the alpha blending, and xrender on linux... one benefit though, is that linking against these libraries has pretty much no size overhead.

Human interaction hardly requires anything more than about 30 frames per second.
this on a 3d gaming/graphics forum is the equivalent of starting a small "32bit / 64bit precision" or "daw A vs daw B" discussion on an audio related forum :-) ! the debate is very old ...

this is an article that explain:
http://www.tweakguides.com/Graphics_5.html
in short, 30fps look good on a movie because there is motion blur between the frames. this originally is the effect of the film rolling i believe.

there is also a small program for download in there called "FPS Compare (old) (106KB)" that will try prove some of the statements.

i've noticed these differences some time after the game quake came out around 1996. i was fortunate enough to have a fairly decent computer at that time... and there was a parameter in the game to tweak the maximum fps.




---

[Analogy]

in short, 30fps look good on a movie because there is motion blur between the frames. this originally is the effect of the film rolling i believe.

The actual cause of motion blur goes back to when the film is exposed - every frame, the shutter is held open long enough for enough light to fall on the film to expose it properly. Anything moving during the exposure leaves a blurry trail - motion blur. When the movie is projected the film is actually held perfectly still while the projector is shining light through the frame. A shutter cuts off the light while the film is advanced to the next frame. You do not see the film rolling.

When frames are shown in sequence, the motion blur acts as a sort of "temporal anti-aliasing," smoothing out apparent motion in the same way that anti-aliasing a font or other computer generated image causes it to look smooth instead of blocky.

[liteon]

OT:
The actual cause of motion blur goes back to when the film is exposed - every frame, the shutter is held open long enough for enough light to fall on the film to expose it properly. Anything moving during the exposure leaves a blurry trail - motion blur. When the movie is projected the film is actually held perfectly still while the projector is shining light through the frame. A shutter cuts off the light while the film is advanced to the next frame. You do not see the film rolling.

When frames are shown in sequence, the motion blur acts as a sort of "temporal anti-aliasing," smoothing out apparent motion in the same way that anti-aliasing a font or other computer generated image causes it to look smooth instead of blocky.

this is cool info,
never thought much of how a camera works, and it makes a lot more sense now...



---

[Tale]

These are the results on my Intel Core 2 Duo E6300 1.86 GHz / Nvidia GeForce 9500 GT:

Schwa's testapp.exe:
-----------------------------
GDI+ LICE
lines: 0.468 0.064 7.3X
curves: 0.772 0.311 2.5X
circles: 0.509 0.056 9.1X
filled circles: 0.353 0.231 1.5X

Justin's testapp.exe:
-----------------------------
GDI+ LICE
lines: 0.477 0.058 8.2X
curves: 0.770 0.237 3.2X
circles: 0.816 0.101 8.1X

I have a slightly faster computer at home (an Intel Core 2 Duo E6600 2.40 GHz) with a slightly lesser graphics card (Nvidia GeForce 8400 GS), so I thought I'd run the tests on that machine as well. These are the results:

Schwa's testapp.exe:
-----------------------------
GDI+ LICE
lines: 0.493 0.051 9.7X
curves: 0.795 0.272 2.9X
circles: 0.532 0.045 11.8X
filled circles: 0.366 0.200 1.8X

Justin's testapp.exe:
-----------------------------
GDI+ LICE
lines: 0.498 0.047 10.6X
curves: 0.794 0.219 3.6X
circles: 0.820 0.089 9.2X

When I compare these results with my earlier test at work, it clearly shows that LICE performs better on an E6600 than on an E6300, which is expected. However, GDI+ doesn't perform better on the E6600 machine, it performs worse. I think this is because of the lesser graphics card. So tt would seem that LICE benefits more from a fast CPU, while GDI+ benefits more from a fast graphics card.

[todd_r]

2nd Testapp
Ubuntu 10.04
Linux 2.6.32-22-generic (i686)
Wine 1.2 rc3
Intel Core2Duo P8600
GeForce 9300M GS - Driver Version:195.36.24
Fullscreen
________________________________________________

Lice

Lines 19.222
Curves 14.135
Circles 19.499

GDI+

Lines 0.098
Curves 0.132
Circles 0.064

________________________________________________


The GDI+ results stay pretty steady, but the Lice results vary, they seem to slowly creep up as the complexity increases

I've always thought that redraws were a little slow using Reaper under wine, and this seems to confirm this, I dont get the same problem with other windows apps that I assume are using GDI+. Anyone any idea what's going on here

[todd_r]

Just tried wine with native GDI+ (ie microsoft) just fyi, lice results stayed the same

GDI+

Lines 155.783
Curved 245.466
Circles 313.296

Rome are you using native or builtin gdi+ in wine?

[synth]

- Raw GPU power is what you need for better scores in this 'benchmark'. The 2D rendering tests barely use any CPU resources.

- Justin's ICC build performs slower on modern AMD CPUs

- Windows XP has much better 2D performance than Windows 7. The difference in performance between LICE and GDI+ is much greater under WinXP.

- LICE is a whole lot faster than GDI+:

6x faster (lines)
2x faster (curves)
6.7x faster (circles)
1.6x faster (filled circles)

on an AMD Phenom II 955 w/ onboard ATI HD3300 graphics, Windows 7 32-bit

[todd_r]

Anyone any idea why my results with lice under wine aren't too good?

[Ollie]

If you compare the results here, it looks very much like the results are really going through the roof when a decent GPU is involved and a bit less stellar e.g. on my IGPs. So in my theory, the lack of a driver utilizing HW acceleration functions or generic drivers and/or a slow GPU could do that to your results, plus everything seem to be generally slower on WINE which is probably no surprise. I may be wrong. :)

[airon]

i7 920, 1366 RAM, 9800GT GPU, Win7 x64

I let each test run for at least 30 seconds before recording the value.

Lice(GDI):

Lines 63ms (788)
Curves 243ms(980)
Circles 61ms (750)
Filled Circles 246 ms(after a while) (~850ms)

[juliansader]

Is the original .cpp file perhaps still available for download somewhere?

I am trying to learn more about LICE, so it would be helpful to see a simple example of LICE and GDI doing the same actions.