[Mono-winforms-list] MWF painting VERY slow compared to .NET
Peter Dennis Bartok
peter at novonyx.com
Thu Jul 28 18:08:57 EDT 2005
Here are my results:
Image: 800x600 pixels:
* Win32, MS.Net: 32fps
* Win32, MWF.dll, rest MS.Net: 31.25fps
* Linux (NLD), Mono: 3.54fps (remote Win32 X server, over the network)
* Linux (NLD), Mono: 3.8fps (remote Xfree X server, over the network)
* Linux (NLD), Mono: 5.73fps (local Xfree X server)
* Mac OS X, Mono: 2.5fps (with the X11 driver)
Image: 100x80
* Win32, MS.Net: 1612fps
* Win32, MWF.dll, rest MS.Net: 1581fps
* Linux (NLD), Mono: 3.55fps (remote Win32 X server, over the network)
* Linux (NLD), Mono: 354.33fps (remote Xfree X server, over the network)
* Linux (NLD), Mono: 227.28fps (Local Xfree X server)
* Mac OS X, Mono: not tested
Image: 100x40
* Win32, MS.Net: 2497fps
* Win32, MWF.dll, rest MS.Net: 1581fps
* Linux (NLD), Mono: 3.50fps (remote Win32 X server, over the network)
* Linux (NLD), Mono: 518.18fps (remote Xfree X server, over the network)
* Linux (NLD), Mono: 353.33fps (Local Xfree X server)
* Mac OS X, Mono: not tested
Image: 100x20
* Win32, MS.Net: 2649fps
* Win32, MWF.dll, rest MS.Net: 1581fps
* Linux (NLD), Mono: 3.70fps (remote Win32 X server, over the network)
* Linux (NLD), Mono: 561.95fps (remote Xfree X server, over the network)
* Linux (NLD), Mono: 486.84fps (Local Xfree X server)
* Mac OS X, Mono: 56fps (with the X11 driver)
My conclusions:
* While we are a bit slower with our MWF dll, it's pretty obvious that the
bottleneck is not MWF, but the drawing code.
* The X11 message loop is not the problem, we get high speeds with our
existing loop, if the image is small.
* My Win32 X server is pathetic (I'm guessing that's because it doesn't
support the Xrender extension)
* As someone just put it, I'd say it's pretty obvious that Cairo "sucks
donkey ass" when it comes to handling large images. This is on Cairo 0.3.0 ,
which was absolutely not optimized. Cairo is currently at version 0.5.0 and
we have someone who's moving our libgdplus to that newer version. Once that
is complete we can compare (and look into optimizations on the cairo or our
libgdiplus side) One caveat here: It might be X itself that sucks donkey ass
with large images, maybe I find some time to test that tonight.
Cheers,
Peter
-----Original Message-----
From: "Peter De Jager" <peterdj at telkomsa.net>
To: "'Peter Dennis Bartok'" <peter at novonyx.com>; "'Miguel de Icaza'"
<miguel at ximian.com>
Cc: <mono-winforms-list at lists.ximian.com>
Date: 28 July, 2005 15:15
Subject: RE: [Mono-winforms-list] MWF painting VERY slow compared to .NET
>I'm attaching a small code snippet. You *should* use Invoke() instead of
>painting to a Form directly, but in this (very simple) example, no other
>thread is painting to the form so it should be safe.
>
>You can compile with .NET or mcs. Put an image file, "Image.png", in the
>same directory as the executable before running it. The image should be
>smaller than approx. 800x600 otherwise it will be clipped. When the form is
>displayed, it shows nothing (not even a background, except on Mono where
>the
>background is incorrectly painted). When you click on the form, it
>repeatedly paints the bitmap to the form and displays the mean frame rate
>over a 10 second period. On my hardware (and using my "Image.png"), the
>figures at the end of the 10 seconds are 162 for .NET and 7.65 for Mono.
>
>With regards to Mac, I know very little about X11 (as with Linux). To be
>honest, I don't even understand your question ;-). When trying to get MWF
>and gtk-sharp running I saw on the mailing lists that X11 needs to be
>installed, so I did that. I also tried to run 'mono.exe' from an X11
>terminal (I don't know how this differs from a normal terminal on Mac).
>After macpack I've managed to get a MWF app displaying for an instant
>before
>quitting, so my success has been limited so far. However, all of my non-gui
>code is running without problems under Mono on OS X, albeit at
>approximately
>half the speed of Mono on Linux (FC 4), on the same PowerPC hardware.
>
>Pete.
>
>
>> -----Original Message-----
>> From: Peter Dennis Bartok [mailto:peter at novonyx.com]
>> Sent: Thursday, July 28, 2005 20:25
>> To: Peter De Jager; 'Miguel de Icaza'
>> Cc: mono-winforms-list at lists.ximian.com
>> Subject: Re: [Mono-winforms-list] MWF painting VERY slow
>> compared to .NET
>>
>> Peter,
>>
>> I am curious as to how you tested performance/framerate. Any
>> chance you could provide the code? (Binary should be ok,
>> doesn't have to be source yet). I'd love to go through and
>> see where we spend the cycles. (And I will also test with our
>> MWF but Microsoft's GDI+ on Win32, which will give an idea of
>> how much impact our managed approach to drawing controls has)
>>
>> When Jackson worked on improving performance of the X11
>> driver's event loop, he went through the Gtk+ code, so I'd
>> assume he modeled it after theirs and we should have the same
>> benefits.
>>
>> Also, you mention OS X. Are you testing with the X11 driver
>> or with the OS X driver?
>>
>> Also, so far we have spent little time optimizing things,
>> we've only tried to get to a code-complete state, but we're
>> reaching the point where we're looking into performance, so
>> you picked the perfect time to bring up the issue :-)
>>
>> Cheers,
>> Peter
>>
>> -----Original Message-----
>> From: "Peter De Jager" <peterdj at telkomsa.net>
>> To: "'Miguel de Icaza'" <miguel at ximian.com>
>> Cc: <mono-winforms-list at lists.ximian.com>
>> Date: 28 July, 2005 12:08
>> Subject: RE: [Mono-winforms-list] MWF painting VERY slow
>> compared to .NET
>>
>>
>> >That would make sense. It almost appears as if the MWF event loop is
>> >clocked at a fixed frequency, resulting in the (almost) fixed frame
>> >rate regardless of architecture or video drivers. Of course
>> it will be
>> >more complex than that, but it does appear that the delay is
>> at least
>> >in part due to the event loop.
>> >
>> >What would be the best way to proceed though? In the last few days I
>> >have tried gtk-sharp on Mac without much success, having had
>> a lot of
>> >trouble installing gtk-sharp under PowerPC (at least with Mono 1.1.8
>> >and FC4). I saw the post by Attila Balogh who provides a
>> modified Mono
>> >framework for OS X Tiger (90MB), which includes gtk-sharp
>> 1.0.10, but I
>> >haven't tried it yet.
>> >I
>> >thought I'd hold out for a while and keep testing on Linux
>> (Intel/PPC)
>> >using MWF. I've also had a look at wx.Net but it appears
>> that gtk-sharp
>> >is more widely supported. In a perfect world I would use MWF
>> since this
>> >requires no change from my .NET code, but failing that, I
>> was hoping to
>> >use a single GUI toolkit for both Linux and OS X. Does gtk-sharp fit
>> >the bill?
>> >
>> >Pete.
>> >
>> >
>> >> -----Original Message-----
>> >> From: Miguel de Icaza [mailto:miguel at ximian.com]
>> >> Sent: Thursday, July 28, 2005 19:32
>> >> To: vlindos at nucleusys.com
>> >> Cc: Peter De Jager; mono-winforms-list at lists.ximian.com
>> >> Subject: Re: [Mono-winforms-list] MWF painting VERY slow
>> compared to
>> >> .NET
>> >>
>> >> Hello,
>> >>
>> >> > Slowness of MWF drawing comes from Cairo. MWF uses
>> libgdiplus for
>> >> > drawing, libgdiplus uses cairo/libpixmain backends for
>> drawing and
>> >> > uses version 0.3.0 of Cairo. Currently Cairo is version
>> 0.5.2. The
>> >> > problem is that Cairo isn't yet stable project as API is
>> >> changed even
>> >> > on minor version change. On mailing lists of Cairo there
>> is talk of
>> >> > soon releasing of version 1 which means freezing the API.
>> >> But 'soon'
>> >> > could be month or year by my opinion.
>> >>
>> >> Although Cairo is known to be a part of the problem,
>> another part of
>> >> the equation might be the event loop processing.
>> >>
>> >> I do not remember the details, but Gtk+ spent quite a bit of time
>> >> dealing with improving their main loop and event processing to
>> >> improve performance.
>> >>
>> >> Miguel.
>> >>
>> >
>> >_______________________________________________
>> >Mono-winforms-list maillist - Mono-winforms-list at lists.ximian.com
>> >http://lists.ximian.com/mailman/listinfo/mono-winforms-list
>> >
>> >
>>
>>
>
More information about the Mono-winforms-list
mailing list