Re: [Mono-winforms-list] Re: [Mono-dev] Help contributingtolibgdiplusand Cairo integration
Hi, You are partially right as some methods use DrawFrameControl but others use GDI+ while others use other GDI functions. So ControlPaint uses a mixture of different drawing functions that results in an inconsistent design.:) Kornél - Original Message - From: "Peter Dennis Bartok" <[EMAIL PROTECTED]> To: "Kornél Pál" <[EMAIL PROTECTED]>; "Jordi Mas" <[EMAIL PROTECTED]>; "Jonathan Gilbert" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, October 05, 2005 8:47 PM Subject: Re: [Mono-winforms-list] Re: [Mono-dev] Help contributingtolibgdiplusand Cairo integration >...Look at ControlPaint class. In MWF it wraps ThemeEngine but in MS.NET it probably really implements drawing and is probably used by the above controls. ControlPaint is a wrapper around the Win32 DrawFrameControl method. ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/pantdraw_4b3g.asp ) Cheers, Peter ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
RE: [Mono-winforms-list] Help contributing to libgdiplus and Cairointegration
I took a look at the paper and tried some things out. It didn't seem to solve the issue at hand. There seems to be two problems. 1. The issue of line thickness. This problem is handled by the Hobby pens described in the paper (lines of uniform thickness will be produced). 2. The more noticeable issue. Cairo handles pixels at halves instead of integers (so (0,0) is really (.5,.5) ), or so I have been told. From what I understand this is causing the issue. The Hobby paper (as well as the average user of System.Drawing) assumes that pixel centers are at integer coordinates. This seems to be what is causing the funny looking lines. Notice that the Hobby pen for a line of diameter 1 is the same polygon pen that is generated by Cairo at this time, a diamond with vertices at points (.5,0),(0,.5),(-.5,0),(0,-.5). So until Cairo works right with a pen of width 1, there is still an issue. So I think the Hobby pens would help eventually if implemented, but I don't think they will work correctly until issue 2 is resolved in some manner. Also, I am not an expert nor claim to be :-) - Jonathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jordi Mas Sent: Wednesday, October 05, 2005 9:15 AM To: mono-winforms-list@lists.ximian.com Subject: [Mono-winforms-list] Help contributing to libgdiplus and Cairointegration Hi all! As you probably know Cairo 1.0 includes antialiasing support. This is something important for libgdiplus because all the drawing operations in System.Windows.Forms are based on the old Windows GDI and they use no antialiasing. After turning antialiasing off in Cairo 1.0 we noticed that DrawLine and other functions basic drawing functions started to work different that expected. With antialiasing off in Cairo lines that are supposed to be a single pixel width have various variations in width. This a well-know and documented issue. John Hobby did his PhD on the solution to this problem. There is a shorten version of PhD findings on the web: [Hobby89] John D. Hobby, Rasterizing Curves of Constant Width, JACM 36(2), 1989. http://cm.bell-labs.com/who/hobby/87_2-04.pdf In order to fix this problem the best solution is to implement an algorithm to generate Hobby's "Pen polygons". These respect the desired width and will make us to look right when AA is off. According to Cairo hacker's, a hack in cairo-pen.c:_cairo_pen_init with Hobby's algorithm will fix the problem. We are looking for someone that wants to contribute to the Mono project in graphics area and help us implementing Hobby's Pen polygons in Cairo. Thanks, Jordi, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Re: [Mono-dev] Help contributingtolibgdiplus and Cairo integration
>...Look at ControlPaint >class. In MWF it wraps ThemeEngine but in MS.NET it probably really >implements drawing and is probably used by the above controls. ControlPaint is a wrapper around the Win32 DrawFrameControl method. ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/pantdraw_4b3g.asp ) Cheers, Peter ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Re: [Mono-dev] Help contributing tolibgdiplus and Cairo integration
> They are wrappers around native windows but most of them are drawn using > GDI+ using managed code unless you set FlatStyle to System. These are: > Button, CheckBox, RadioButton, Label and GroupBox. Look at ControlPaint > class. In MWF it wraps ThemeEngine but in MS.NET it probably really > implements drawing and is probably used by the above controls. > > Some more complex controls like ListView are drawn by Windows (in this case > by comctl32.dll) anyway and there is no FlatStyle property. There are some, that are implemented on top of System.Drawing (DataGrid for example also), but most of them are native: ListBox, Menus, ComboBox, ListView, ScrollBars, StatusBar, ToolBars, Tabs, TreeView, etc. Jordi, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Re: [Mono-dev] Help contributing tolibgdiplus and Cairo integration
Microsoft implemented System.Windows.Forms as a thin wrapper on top of the Win32 API not on top of System.Drawing like we are doing (that's because we call our implementation managed). Most of Microsoft SWF controls are native and these ones do not use GDI+. I hope that this helps to clarify. They are wrappers around native windows but most of them are drawn using GDI+ using managed code unless you set FlatStyle to System. These are: Button, CheckBox, RadioButton, Label and GroupBox. Look at ControlPaint class. In MWF it wraps ThemeEngine but in MS.NET it probably really implements drawing and is probably used by the above controls. Some more complex controls like ListView are drawn by Windows (in this case by comctl32.dll) anyway and there is no FlatStyle property. But just to make sure that people who want to contribute this know: The help we need is simply to implement proper non-antialiased drawing in Cairo. People who want to contribute this don't have to have experience in Windows, GDI, GDI+, libgdiplus, Mono or System.Drawing. This is a general drawing related problem and only Cairo has to be modified. This makes the things a bit easier. And also not that proper non-antialiased drawing is something that should be supported by Cairo and System.Drawing anyway so we don't need it just because Windows uses GDI that is old, we need it because it should be supported. Kornél - Original Message - From: "Jordi Mas" <[EMAIL PROTECTED]> To: "Jonathan Gilbert" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, October 05, 2005 7:44 PM Subject: Re: [Mono-winforms-list] Re: [Mono-dev] Help contributing tolibgdiplus and Cairo integration El dc 05 de 10 del 2005 a les 12:49 -0500, en/na Jonathan Gilbert va escriure: I don't have much to say about the rest of the e-mail, but this last statement is not true. System.Windows.Forms uses System.Drawing for all of its drawing needs, and System.Drawing is a relatively thin wrapper of GDI+, Jonathan, Microsoft implemented System.Windows.Forms as a thin wrapper on top of the Win32 API not on top of System.Drawing like we are doing (that's because we call our implementation managed). Most of Microsoft SWF controls are native and these ones do not use GDI+. I hope that this helps to clarify. Jordi, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] Re: [Mono-dev] Help contributing to libgdiplus and Cairo integration
El dc 05 de 10 del 2005 a les 12:49 -0500, en/na Jonathan Gilbert va escriure: > I don't have much to say about the rest of the e-mail, but this last > statement is not true. System.Windows.Forms uses System.Drawing for all of > its drawing needs, and System.Drawing is a relatively thin wrapper of GDI+, Jonathan, Microsoft implemented System.Windows.Forms as a thin wrapper on top of the Win32 API not on top of System.Drawing like we are doing (that's because we call our implementation managed). Most of Microsoft SWF controls are native and these ones do not use GDI+. I hope that this helps to clarify. Jordi, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] Re: [Mono-dev] Help contributing to libgdiplus and Cairo integration
At 03:15 PM 05/10/2005 +0200, Jordi Mas wrote: >Hi all! > >As you probably know Cairo 1.0 includes antialiasing support. This is >something important for libgdiplus because all the drawing operations in >System.Windows.Forms are based on the old Windows GDI and they use no >antialiasing. I don't have much to say about the rest of the e-mail, but this last statement is not true. System.Windows.Forms uses System.Drawing for all of its drawing needs, and System.Drawing is a relatively thin wrapper of GDI+, not the old GDI32. This is why libgdiplus is named the way it is; it is a copy of the new library Microsoft introduced in Windows 2000. GDI32 is invoked only at the very back end where it needs to copy GDI+ Bitmaps onto GDI32 DCs. You can enable anti-aliasing with: Graphics my_graphics = ...; my_graphics.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.AntiAlias; Just thought I'd chime in with this, as it may be useful to any readers who are using System.Drawing :-) Jonathan Gilbert ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
[Mono-winforms-list] Help contributing to libgdiplus and Cairo integration
Hi all! As you probably know Cairo 1.0 includes antialiasing support. This is something important for libgdiplus because all the drawing operations in System.Windows.Forms are based on the old Windows GDI and they use no antialiasing. After turning antialiasing off in Cairo 1.0 we noticed that DrawLine and other functions basic drawing functions started to work different that expected. With antialiasing off in Cairo lines that are supposed to be a single pixel width have various variations in width. This a well-know and documented issue. John Hobby did his PhD on the solution to this problem. There is a shorten version of PhD findings on the web: [Hobby89] John D. Hobby, Rasterizing Curves of Constant Width, JACM 36(2), 1989. http://cm.bell-labs.com/who/hobby/87_2-04.pdf In order to fix this problem the best solution is to implement an algorithm to generate Hobby's "Pen polygons". These respect the desired width and will make us to look right when AA is off. According to Cairo hacker's, a hack in cairo-pen.c:_cairo_pen_init with Hobby's algorithm will fix the problem. We are looking for someone that wants to contribute to the Mono project in graphics area and help us implementing Hobby's Pen polygons in Cairo. Thanks, Jordi, -- Jordi Mas i Hernàndez - Mono development team - http://www.mono-project.com Homepage and LiveJournal at http://www.softcatala.org/~jmas ___ Mono-winforms-list maillist - Mono-winforms-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-winforms-list
Re: [Mono-winforms-list] 1.1.9.1 Native Winforms Crash on OSX
Hi Jonathan. Thanks for the answer.
Yes, the code for the simple app im doing is:
using System.Drawing;
using System.Windows.Forms;
namespace testwforms
{
public clas
mesagebox
{
static void
Main()
{
MesageBox.Show("Helo World");
}
}
}
Im saving it as test.cs, and what im ussing to
compile it is:
mcs /t:winexe /r:system.drawing.dll
/r:system.windows.forms.dll test.cs
then, mackpacking it as...
macpack -a:test.exe -o:. -m:1 -n:test
The error report is the next
Date/Time: 2005-10-03
14:06:36.852 -0300OS Version: 10.4.2 (Build
8C46)Report Version: 3
Command: monoPath:
/usr/bin/monoParent: sh [1129]
Version: ??? (???)
PID: 1137Thread:
2
Exception: EXC_BAD_ACCESS
(0x0001)Codes: KERN_INVALID_ADDRESS (0x0001)
at 0xa0384200
Thread 0:0
libSystem.B.dylib
0x90056418 semaphore_timedwait_signal_trap + 81
libSystem.B.dylib
0x90056284 pthread_cond_timedwait + 7042
mono
0x00157d50 timedwait_signal_poll_cond + 164
(handles.c:1251)3
mono
0x00158118 _wapi_handle_timedwait_signal_handle + 520
(handles.c:1338)4
mono
0x00144e08 WaitForSingleObjectEx + 572 (wait.c:181)5
mono
0x0012a7ac mono_domain_finalize + 272 (gc.c:214)6
mono
0x00032278 mini_cleanup + 44 (mini.c:10280)7
mono
0x5500 mono_main + 4468 (driver.c:942)8
mono
0x2e14 main + 40 (main.c:6)9
mono
0x28dc _start + 392 (crt.c:267)10
dyld
0x8fe01048 _dyld_start + 60
Thread 1:0
libSystem.B.dylib
0x90042ae8 mach_wait_until + 81
libSystem.B.dylib
0x900428a0 nanosleep + 3842
mono
0x00181e14 collection_thread + 60 (collection.c:43)3
libSystem.B.dylib
0x9002c3b4 _pthread_body + 96
Thread 2 Crashed:0
<<>> 0xfffeff20 objc_msgSend_rtp + 321
<<>> 0x04f106c0 0 + 829047682
<<>> 0x04f10360 0 + 829039043
<<>> 0x04f101a8 0 + 829034644
<<>> 0x04f0ffb4 0 + 829029645
<<>> 0x04f0ff14 0 + 829028046
<<>> 0x04f0fe08 0 + 829025367
<<>> 0x04f0fd70 0 + 829023848
<<>> 0x04f0fd38 0 + 829023289
<<>> 0x04f0fcdc 0 + 8290223610
<<>> 0x04f0fbe4 0 + 8290198811
mono
0x00030c50 mono_jit_runtime_invoke + 280 (mini.c:9649)12
mono
0x000a459c mono_runtime_invoke + 84 (object.c:1311)13
mono
0x0012a4b4 run_finalize + 328 (gc.c:105)14
mono
0x0012ba5c finalize_domain_objects + 180 (gc.c:647)15
mono
0x0012bb9c finalizer_thread + 244 (gc.c:685)16
mono
0x000aab84 start_wrapper + 300 (threads.c:297)17
mono
0x0016046c timed_thread_start_routine + 284
(timed-thread.c:134)18
libSystem.B.dylib
0x9002c3b4 _pthread_body + 96
Thread 3:0
libSystem.B.dylib
0x9000a738 mach_msg_trap + 81
libSystem.B.dylib
0x9000a67c mach_msg + 602
com.apple.CoreFoundation 0x9074b338 __CFRunLoopRun +
8323 com.apple.CoreFoundation 0x9074ac3c
CFRunLoopRunSpecific + 2684
com.apple.CoreFoundation 0x9075a09c CFRunLoopRun +
525 tw.com.sonix.webcam.sn9c102 0x052e8a68
Bridge::installDeviceRemovedNotification(void*) + 4526
libSystem.B.dylib
0x9002c3b4 _pthread_body + 96
Thread 2 crashed with PPC Thread State
64: srr0: 0xfffeff20 srr1:
0x0200f030
vrsave: 0x cr:
0x44000442 xer:
0x2001 lr: 0x04f106c0 ctr:
0xfffeff00 r0: 0x04f106c0 r1:
0xf01037c0 r2: 0xa0384200 r3:
0x02b4f1c0 r4: 0x90a16918 r5:
0x0072 r6: 0xa09a88b4 r7:
0x907dd554 r8: 0x3227 r9:
0x90a1691f r10: 0x0001 r11:
0x6f5f6918 r12: 0x00020bbb r13:
0x r14: 0x r15:
0x r16: 0x r17:
0x r18: 0x r19:
0x r20: 0x r21:
0x r22: 0x r23:
0x02b527a0 r24: 0x00744ec0 r25:
0x02b4f1c0 r26: 0x00746e70 r27:
0x00745600 r28: 0x02b4f1c0 r29:
0x018054f0 r30: 0xf0103bb0 r31:
0xf0103af0
Binary Images Description:
0x1000 - 0x1d6fff mono /usr/bin/mono 0x48c000
- 0x48efff libgthread-2.0.0.dylib
/Library/Frameworks/Mono.framework/Versions/1.1.9.1/lib/libgthread-2.0.0.dylib
0x492000 - 0x494fff libgmodule-2.0.0
