Maybe weirdness was the wrong word. Sometimes I hit things that are not implemented (which is fine, and maybe I could even look into these things). Right now I am mainly seeing issues with Regions/Clipping, as this is what I am trying to use.
Thanks for the advice, Jonathan -----Original Message----- From: Peter Dennis Bartok [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 4:39 PM To: Jonathan S. Chambers; [email protected] Subject: Re: [Mono-winforms-list] Double Buffering To debug unmanaged code I use gdb. A few mono-specific gdb things I do: Make sure your ~/.gdbinit contains this line: handle SIGPWR SIGXCPU noprint nostop pass Run the mono app inside gdb: gdb --args mono app.exe <app args> Set a breakpoint in unmanaged code: break <function> (e.g. break MeasureOrDrawString) Answer y on this question:Make breakpoint pending on future shared library load? (y or [n])) Find out where you are: bt (or, if it crashed, you might want to do 'thread apply all bt' to get a backtrace on all threads) Translate an address on the stack into a managed method: print print_method_from_ip(address) Example: (gdb) bt #0 gdip_graphics_init (graphics=0x966d258) at graphics.c:42 #1 0x00470a7d in gdip_graphics_new () at graphics.c:71 #2 0x004808ac in GdipGetImageGraphicsContext (image=0x9668280, graphics=0xfef72e30) at image.c:131 #3 0x00209960 in ?? () #4 0x09668280 in ?? () #5 0xfef72e30 in ?? () #6 0x000c87a0 in ?? () #7 0x092573e8 in ?? () #8 0x090c87b8 in ?? () #9 0x090c87a0 in ?? () #10 0x0966bf80 in ?? () #11 0x00000000 in ?? () (gdb) print print_method_from_ip (0x00209960) IP 0x209960 at offset 0x30 of method (wrapper managed-to-native) System.Drawing.GDIPlus:GdipGetImageGraphicsContext (intptr,intptr&) (0x209930 0x209984)[domain 0x9108f00 - text.exe] $3 = void With a little bit of practice you can pick out which numbers are managed function addresses Hope this helps. What kind of System.Drawing weirdness are you experiencing? Cheers, Peter -----Original Message----- From: "Jonathan S. Chambers" <[EMAIL PROTECTED]> To: "Peter Dennis Bartok" <[EMAIL PROTECTED]>; <[email protected]> Date: 03 May, 2005 14:27 Subject: RE: [Mono-winforms-list] Double Buffering Yes, I'm using double buffering in the property grid now. With the change to Control.cs to support double buffering it was easy, as well as changing the code to override OnPaint instead of WndProc. I've done a decent bit of .Net development, but very little native linux development. I'm trying to draw the control as efficiently as possible but seem to run into quirks in System.Drawing (which is forwarding calls to unmanaged code). Any advice for debugging unmanaged code on Linux? I've been spoiled by my years of using the Visual Studio IDE on Windows. Thanks, Jonathan -----Original Message----- From: Peter Dennis Bartok [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 4:19 PM To: Jonathan S. Chambers; [email protected] Subject: Re: [Mono-winforms-list] Double Buffering Yeah, I had a look at it when you originally posted, but since I couldn't test at the time (working on richtext), it slipped my mind. Thanks for the reminder. I just committed a modified version, one that doesn't redraw the whole clientrectangle bitmap every time, but only the exposed area. Thanks for catching this! I'm guessing you're using now double-buffering in PropertyGrid? Cool. Cheers, Peter -----Original Message----- From: "Jonathan S. Chambers" <[EMAIL PROTECTED]> To: <[email protected]> Date: 03 May, 2005 13:40 Subject: RE: [Mono-winforms-list] Double Buffering Anyone take a look at this patch? I'm planning on checking in some updates to the propertygrid, and this patch would cause redrawing of the control to work correctly. Thanks, Jonathan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan S. Chambers Sent: Thursday, April 28, 2005 8:52 PM To: Jonathan S. Chambers; [email protected] Subject: RE: [Mono-winforms-list] Double Buffering Sorry about the message flurry. XplatUI.PaintEventEnd(Handle) wasn't being called in quick repainting logic. Thanks, Jonathan -----Original Message----- From: [EMAIL PROTECTED] on behalf of Jonathan S. Chambers Sent: Thu 4/28/2005 8:40 PM To: Jonathan S. Chambers; [email protected] Cc: Subject: RE: [Mono-winforms-list] Double Buffering The first patch is valid. The second is not. The logic looks like it still needs fixed (when should needs_redraw be set to false), but my solution does not seem to be working... -----Original Message----- From: [EMAIL PROTECTED] on behalf of Jonathan S. Chambers Sent: Thu 4/28/2005 8:31 PM To: Jonathan S. Chambers; [email protected] Cc: Subject: RE: [Mono-winforms-list] Double Buffering Also, the setting of 'needs_redraw = false' (line 3181) should be moved outside of the if block. Notice that it can never actually get inside the if block, since that is the only place needs_redraw is set to false. - Jonathan -----Original Message----- From: [EMAIL PROTECTED] on behalf of Jonathan S. Chambers Sent: Thu 4/28/2005 8:21 PM To: [email protected] Cc: Subject: [Mono-winforms-list] Double Buffering I noticed that support for double buffering has been included in Control.cs. This is nice, except that I think the two calls to DrawImage (lines 3177 and 3195) should pass ClientRectangle as the second parameter, rather than ClipRectangle of the paint event args. According to MS documentation, and actual behavior, "The image represented by the image object is scaled to the dimensions of the rect rectangle." Thus with the code as is, the code as is draws the ImageBuffer to the ClipRectangle. When the clip rectangle is the entire control, this makes sense. However, when the clip rectangle is just part of the control (like when a partially obstructing window is removed) the whole control is drawn to the clip area. (I can send an image if anyone wants to see). Thanks, Jonathan _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list _______________________________________________ Mono-winforms-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-winforms-list
