[Mono-list] [Fwd: Re: System.Drawing (libart, gdkpixbuf)]

Dan Nedelko dan@genuinemedia.com
10 Apr 2002 21:07:48 -0400


Hi Christian,

We chatted on #mono a couple of weeks ago and I'd be happy to pitch in.

Dan Nedelko

On Wed, 2002-04-10 at 15:13, Christian Meyer wrote:
> Just forwarding my previous mail...
> 
> -------------------------------------------------------------------
> Hi!
> 
> sorry for the late answer. I just came back from Spain yesterday at
> 11:30 pm.
> 
> Am Son, 2002-04-07 um 15.24 schrieb Miguel de Icaza:
> > Hello Christian,
> > 
> >    It was great meeting you at GUADEC.  I think we should have had a
> > Mono BOF, but it was too late by the time I thought of it ;-(
> 
> Yeah. That would have been great.
>  
> >    Anyways, here are my thoughts:
> > 
> > 	* gdk-pixbuf is a generic image loader that loads an image
> > 	  and leaves it into an RGB buffer.  It hides all the details
> > 	  about what image file format is being loaded.
> >
> > 	* Libart is a general framework for rendering RGB/RGBA buffers
> > 	  into RGB buffers and rendering postscript-like paths into
> > 	  RGB/RGBA buffers.
> 
> OK, sounds easy.
>  
> >    So we want to use gdk-pixbuf as the image loader for the image
> > classes, and then we need operations to render that into the windowing
> > system (Gtk+, MacOS, etc).  But notice how there is very little
> > dependnecies in Gdk-pixbuf on gtk, and libart has none.
> > 
> >    They are pretty independent from a windowing system (gdk-pixbuf comes
> > with some "helper" routines for rendering data into a pixmap and to load
> > pixmaps into RGB buffers).
> > 
> >    A few things to keep in mind:
> > 
> > 	* gdk-pixbuf can be used to load images for Gtk+, MacOS X and 	 
> > Windows, it should be pretty portable, although we might need
> > 	  in the future to back-port some new features from Gtk head. 
> > 	  Lets talk to Federico about this, and get a status report.
> 
> OK.
> 
> > 	* Libart is probably only going to be used with X11, as the
> > 	  MacOS X provides the same features in Quartz, and Win32
> > 	  *probably* has that in GDI+.  If not, we should use libart
> > 	  in Win32 as well (or for older Windows systems).
> 
> Sounds like that this will be the most diffcult part. How can we find
> out if GDI+ has that feature?
> 
> > * Directory Layout
> > 
> >    My suggestion is to have:
> > 
> > 	System.Drawing 	(assembly directory)
> > 		System.Drawing.Blah
> > 			Common code for "Blah"
> > 			Stubs for "Blah" to ease ports.
> > 
> > 		Gtk
> > 			System.Drawing.Blah.
> > 				Gtk ports of "System.Drawing.Blah"
> 
> Wouldn't it be better to say Linux instead of Gtk?!
> 
> > 		MacOS
> > 			System.Drawing.Blah
> > 				MacOS ports of "System.Drawing.Blah"
> > 		Win32
> > 			System.Drawing.Blah
> > 				Win32 ports of "System.Drawing.Blah"
> > 
> >     Then we use nant targets to include/exclude the right set of files
> > to create the assembly.
> 
> aha. OK.
>  
> > * Open questions:
> > 
> >     I believe that the graphics contexts that are used to render can
> > accept either libart-like rendering operations and X11-like rendering
> > operations.  This complicates matters, but I am not sure.  Someone needs
> > to investigate this.
> 
> eeeeeek. This seems to be even more complicated. I don't know anything
> about those things.
> Another thing is that university will start on monday and I won't have
> much time for looking closer at that kind of stuff. Does anybody
> volunteer?
> 
> Greetings and thanks for the explanations.
> Christian
> 
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
-- 
-------------------------------------------------
If you find a solution and become attached to it, 
the solution may become your next problem.

(519) 721-4045
dan@genuinemedia.com