Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
On Sat, 11 Mar 2000, Jon M. Taylor wrote: On Fri, 10 Mar 2000, Andreas Beck wrote: int ggiStrechCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy, int dw, int dh); It should does the same as ggiCrossBlit, except it also performs streching. Hehe - that was in old LibGGIs. we took it out for its complexity. Well, it is an atomic drawing op on Savage4 hardware at least. But I agree that it is not necessary to have in LibGGI. Should be in either libGGI2d (imho this belongs there) or in a seperate lib devoted to BITBLT's [clip - there's lots on list] - ggi2D equivalents of all LibGGI drawing primitives that obey the extended markups above. Including text? dinna think that libGGI2D should include fonts/text. It's a complex topic and is better suited with external libs. Like freetype :) - triangles, All flat, no perspective stuff? Makes sense. Non-perspective triangles are acceled on many cards and could be used in some drawing ops. libGGI2D shouldn't have any 3D-specific stuff yet. Or maybe ever? (but sharing with libGGI3D or Mesa or ... is mandatory) polygons, Should this be different from triangles? We'll have to decompose the polygons into triangles or triangle fans in many cases anyway, in order to accelerate them efficiently with some hardware. DrawPolygon(vis, triangle, ...) is just a degenerate case of this. Agreed. I also don't look forward to examining the case of non-convex polys. Decomposing polys is a pain! arbitrarily positioned ellipses and arcs Yes. - rounded-edge rectangles ? Multisource ROP blit, superimposing a circle and a square. Also duable using a modified circle algorithm. IMHO that's actually more accurate. I've done it both ways and prefer this - spline/bezier shapes ? What hardware accelerates these? Does it matter? It's still duable :) - streched (Cross-)blitting. Stretching can be handled by allowing different source and destination geometries. ... Never thought of that :) Now go for it ! Sure. I'll try to collect all the ideas from the mailing list archives and come up with a proposal over the weekend. Is there still any interest in the LibXMI idea, or should I assume that we are trying to design the ideal 2D library from the ground up? libXMI's still interesting... - but I prefer accels :) After all, just about all graphics cards these days can do accelerations. (yes I also have some ulterior motives... a 2D accelerated commandstream over a network as a target simplifies having to broadcast streaming video... long story, later :) G'day, eh? :) - Teunis
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
Rodolphe Ortalo [EMAIL PROTECTED] writes: I'm still interested in libxmi, it _may_ save you some time if it can provide the software-only rendering routines for free. But, of course, a fully new 2D library would be perfect also (but maybe it's a lot of work to do the software emulation). Rodolphe So are we. My (small) company is in urgent need to get something working soon, which gives us 2d functionality like arcs and polygons. So, the libxmi solution sounds like the most feasible at this point. And I do not want to do it all on my own. -- Thomas Mittelstaedt, software developer [EMAIL PROTECTED]
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
On 13 Mar 2000, Thomas Mittelstaedt wrote: Rodolphe Ortalo [EMAIL PROTECTED] writes: I'm still interested in libxmi, it _may_ save you some time if it can provide the software-only rendering routines for free. But, of course, a fully new 2D library would be perfect also (but maybe it's a lot of work to do the software emulation). Rodolphe So are we. My (small) company is in urgent need to get something working soon, which gives us 2d functionality like arcs and polygons. So, the libxmi solution sounds like the most feasible at this point. And I do not want to do it all on my own. Relax, I am doing XMI. I will try to get a prototype XMI/GGI build tree up and running soon. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
On Sun, 12 Mar 2000, Rodolphe Ortalo wrote: On Sat, 11 Mar 2000, Jon M. Taylor wrote: Sure. I'll try to collect all the ideas from the mailing list archives and come up with a proposal over the weekend. Is there still any interest in the LibXMI idea, or should I assume that we are trying to design the ideal 2D library from the ground up? (Oops. Once again the last time... :-)) I'm still interested in libxmi, it _may_ save you some time if it can provide the software-only rendering routines for free. I agree, and after having looked over both LibXMI and the gnu plotutils which use XMI, I think it will work out pretty nicely. LibXMI isn't the ultimate 2D library, but it is here now, tested and used, and for being based on the X11 primitives it is actually pretty well architected. I'm gonna port it and table the other 2D-from-the-ground-up idea for later, if XMI doesn't give other people what they need. But, of course, a fully new 2D library would be perfect also (but maybe it's a lot of work to do the software emulation). I would be quite a bit of work. XMI has a lot more immediate uses and can (hopefully) be ported to the LibGGI environment quickly and easily. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
On Sat, 11 Mar 2000, Jon M. Taylor wrote: Sure. I'll try to collect all the ideas from the mailing list archives and come up with a proposal over the weekend. Is there still any interest in the LibXMI idea, or should I assume that we are trying to design the ideal 2D library from the ground up? (Oops. Once again the last time... :-)) I'm still interested in libxmi, it _may_ save you some time if it can provide the software-only rendering routines for free. But, of course, a fully new 2D library would be perfect also (but maybe it's a lot of work to do the software emulation). Rodolphe
Re: ggi2dDrawArc, ggi2dFillArc
On Fri, Mar 10, 2000 at 03:18:15PM +0100, Christoph Egger wrote: On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote: Hi ! At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a way that makes it more consistent with the other extensions and allowing to HW-Accelerate much of it. I wish to have: int ggiStrechCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy, int dw, int dh); It should does the same as ggiCrossBlit, except it also performs streching. i haven't followed the discussion, but ... Streching with or without CrossBlit comes down to the same accel on some gfx-cards. it would save one accel if we would have such a combined command. But I think, this should go into libggi and not libggi2d... Comments? Christoph Egger E-Mail: [EMAIL PROTECTED] thats all Jan --- -)= Jan Kneschke -- Kiel -- Germany -- http://www.kneschke.de =(-
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
On Sat, 11 Mar 2000, teunis wrote: [on reimplementation of libGGI2D] On Fri, 10 Mar 2000, Andreas Beck wrote: [clip] - There is an urgent need for 2D drawing functionality by several groups. - LibGGI2D is unmaintained and doesn't carry the usual GGI License. So please - those who need it: Get together and rewrite it. Specify all your needs and make a header-style proposal. A few proposals to get you started: - ROP 256 What's this mean? Microsoft's Win32 ROP256 standard. Look in any windows programming book. - arbitrary length patterns for lines and background. - ggi2D equivalents of all LibGGI drawing primitives that obey the extended markups above. - triangles, trapezoids (PM2 can accelerate aligned trapezoids) polygons, arbitrarily positioned ellipses and arcs - rounded-edge rectangles ? special case of circle draw. Really quite simple. - spline/bezier shapes ? Okay a little more complicated. Okay a lot. Look how Java 2.0 handles this one it's not too bad... - streched (Cross-)blitting. Frequently accelerated. BITBLT's are almost -always- accelerated though. I would -love- to see a pipeline proposal: how to handle rendering pipeline. AKA OpenGL's specs :) You have already seen mine, it is LibGGI3D I'm not saying OpenGL is the best way of looking at things... but that style's quite suitable to most accels + most libs. something like: [complex command] - handle clipping; can insert "stencil" bitop to for this...; - [select bitop] - [run series of render-ops] I dunno. The GL state-machine thing is designed the way it is because it was designed to be embedded into hardware. 2D hardware acceleration is not nearly as consistently designed as 3D hardware, usually it is a crazy-quilt of different ways to do things. The only stuff that's really common is the 8514/A style 2D accel set. What this all means is that, unlike GL, we don't have a nice abstraction of a rendering pipeline to stuff everything into. We have to tune the nature of the pipeline code to the hardware in order to optimize it, and having one standard type of 2D graphics pipeline would be too restrictive. X is a good example of why this is bad. bitop - eg. AND/XOR/OR/... + bitmasks... renderops - simpler render commands that are usually acceled. Like lines. And points. And rectangular fills... And BITBLT's. Multisource blits with generic and extensible ROPs can take care of most of that stuff. (and the only request I have for clipping is... Be able to handle stencils and rectangular clipping regions and be able to draw onto stencils :) Sure. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
"Jon M. Taylor" [EMAIL PROTECTED] writes: Sure. I'll try to collect all the ideas from the mailing list archives and come up with a proposal over the weekend. Is there still any interest in the LibXMI idea, or should I assume that we are trying to design the ideal 2D library from the ground up? LibXMI is a rasterization library, not a drawing library. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: LibGGI2D - Was: ggi2dDrawArc, ggi2dFillArc
- triangles, All flat, no perspective stuff? trapezoids (PM2 can accelerate aligned trapezoids) So can Trio64 and up. polygons, Should this be different from triangles? We'll have to decompose the polygons into triangles or triangle fans in many cases anyway, in order to accelerate them efficiently with some hardware. DrawPolygon(vis, triangle, ...) is just a degenerate case of this. Same for triangle strips. ATI 128 cards support these. - spline/bezier shapes ? What hardware accelerates these? Infinite Reality engines. I think SGI visual workstations did as well. Can't remember.
Re: ggi2dDrawArc, ggi2dFillArc
On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote: Hi ! At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a way that makes it more consistent with the other extensions and allowing to HW-Accelerate much of it. I wish to have: int ggiStrechCrossBlit(ggi_visual *src, int sx, int sy, int sw, int sh, ggi_visual *dst, int dx, int dy, int dw, int dh); It should does the same as ggiCrossBlit, except it also performs streching. But I think, this should go into libggi and not libggi2d... Comments? Christoph Egger E-Mail: [EMAIL PROTECTED]
Re: ggi2dDrawArc, ggi2dFillArc
On 8 Mar 2000, Thomas Mittelstaedt wrote:
I have an instant need to be able to draw Arcs, RoundRects and
Polygons etc. So, if somebody of the GGI project can give me
guidance, I can jump right into integrating libxmi, since libggi2d
just does not work. I already installed libxmi. There are a few
customizations that they mention in the main header xmi.h.
Overall, it seems to me that libxmi should be directed so as to use
LibGGI's "DirectBuffer"s to access the framebuffer. Alternatively,
you could use ggi{Draw,Put,Get}Pixel directly... (Maybe it's simpler.)
At installation time one can redefine 3 things:
i) Define MI_PIXEL_TYPE at installation time
ii) MI_CANVAS_DRAWABLE_TYPE can be redefined to describe what a Pixmap
should be.
iii) MI_DEFAULT_MERGE2_PIXEL can be set to a different algorithm than
the Painter's, when pixels are applied to the 'canvas'.
It don't know DirectBuffer or LibGGI basic types well-enough to direct
you. But I have the feeling that Andreas or Marcus could easily tell you
what these macros should be... :-) (LibXMI may need to be recompiled
several times to generate the second stage for 8bpp, 16bpp, etc. Or maybe
LibGGI can take care of this...)
IMO, the drawable type is an array of MI_PIXEL_TYPE (linear framebuffer
abstraction). Like the default.
MI_DEFAULT_MERGE2_PIXEL is primarily useful for transparency management
(alpha channel). In a first step, you can surely use the default settings
(a new pixel replaces an old one).
Is that enough to get basic drawing functionality working together
with GGI? Using cross-blitting from memory could also take care of
clipping.
I think it is enough.
So what are the plans? I have to do something, now!!
:-)) Fiddle with libxmi second stage and try to set things so that libxmi
uses libggi DirectBuffers...
But that was just an idea you know...
Rodolphe
Re: ggi2dDrawArc, ggi2dFillArc
On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote: (set-of-non-overlapping-rectangles) in LibGWT. I have the feeling of initiating too much workload wrt to graphic context switch. (Basically, the way it is done is a loop over all the rectangles composing the region while calling set-GC ; draw .) Oh - yes, I agree, that this imposes quite some unnecessary load. IMHO you'd be better off by backbuffering as soon as you have more than say 2 or 3 rectangles. Backbuffering is one possible solution. But I guess also that I could also reorder LibGWT internal drawing calls to minimize the GC-switches. I'd say yes. It is a huge calling overhead, even if clipping is pretty fast. As long as you use HW-accels, you do each accel call mutiple times, which wastes a lot of time unless we do batched accel. Yes but... it's simple and does not require Z-buffer management (which realistically should be done primarily in hardware). Well, anyway, as you have surely understood, my principal concerns with LibGWT currently are not performance-related. I'd like to have it running with full functionality first! :-) [I lost nearly 6 months scratching my head in front of event dispatching... The solution was too simple.;-)] Yeah. It might make sense to implement a simple z-buffer operations thingy or similar for LibGGI3D and base windowing toolkits on that. Basically that is what they want: Multiple planes stacked on to of each other, with different depth. Yes, it may make sense. And this is probably what Berlin requires. LibGWT has a more narrow ambition... At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a way that makes it more consistent with the other extensions and allowing to HW-Accelerate much of it. Mmm... Yes, surely. Well, the most convenient way is probably to direct you at the documentation of OpenAmulet on the Web. It is accessible via a link on the http://www.openip.org/ web page. Inside the full documentation, the layer that wraps the OS's graphical library is described in the 'GEM' chapter. Basically, this layer is a subset of the X11 drawing functions. You need 'styles' (for lines and for filling). The drawing methods of a GEM object (OpenAmulet is in C++) are: Draw_Arc, Draw_Image (ie a pixmap), Draw_Line, Draw_Lines, Draw_2_Lines, Draw_3_Lines, Draw_Rectangle, Draw_Roundtangle (a useful singularity) and Draw_Text (w/ complex fonts, this: later!). Looking more closely, you'll also see that a Bitblt method is needed (but this one is already available in LibGGI itself). As you can see, this API is pretty simple - and corresponds closely to what you can find in libxmi (or X11). Hence my suggestion to use already available software implementations like LibXMI (over LibGGI directbuffer). Of course, a similar API with hardware acceleration would be wonderful. But maybe this time would be better spent over LibGGI3D (where 2D would only be a specific case). I'd tend to give higher priority to a 2D API personnally, but I am partial on this (I need it :-). Berlin's people would surely have opposite priorities (and a much higher need for hardware accels). Maybe we need both in fact. Rodolphe
Re: ggi2dDrawArc, ggi2dFillArc
[EMAIL PROTECTED] wrote: OK. Especially if LibGGI2D is oriented towards hardware acceleration, complex clipping should not be too much different from hardware chipsets capabilities. Yeah. It might make sense to implement a simple z-buffer operations thingy or similar for LibGGI3D and base windowing toolkits on that. Basically that is what they want: Multiple planes stacked on to of each other, with different depth. Since 'they' is addressed at windowing system implementors, I'll respond here in the name of the berlin project. The situation we have is that we manage a scene graph with polymorphic graphic nodes. Each node defines it's own extension and shape. Further, it can be translucent. This situation can't simply be managed be redrawing 'exposed' graphic nodes. Instead, if a region gets damaged we need to traverse the scene graph and redraw each graphic node which intersects. Yet the problem remains: how can we clip to the shape of the actual parent graphic if it can have arbitrary shapes ? The most common situation is a rectangular graphic. Next comes a transformed rectangle (i.e. if you consider the union of multiple possibly transformed rectangles, you get an arbitrary convex polygon). And finally there are arbitrary shapes. At least for the last we need a stencil buffer. Is there a way to design clipping in GGI which is incremental, i.e. which allows more than none or everything (none being simple scissor and everything being stencil), something in between ? Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a way that makes it more consistent with the other extensions and allowing to HW-Accelerate much of it. speaking about wishlist, may I remember you of one important wish we have: a drawable (visual) store. Some functionality with which we can allocate (hopefully video) memory to draw into which then can be mapped to the screen. Regards,Stefan ___ Stefan Seefeld Departement de Physique Universite de Montreal email: [EMAIL PROTECTED] ___ ...ich hab' noch einen Koffer in Berlin...
Re: ggi2dDrawArc, ggi2dFillArc
Hi ! I don't think LibGGI2D should have arbitrary clipping. I'd leave that to a windowing library or a 3D package. I understand. But I asked this question in the first place because I don't feel totally at ease with the way I/we do clipping over regions (set-of-non-overlapping-rectangles) in LibGWT. I have the feeling of initiating too much workload wrt to graphic context switch. (Basically, the way it is done is a loop over all the rectangles composing the region while calling set-GC ; draw .) Oh - yes, I agree, that this imposes quite some unnecessary load. IMHO you'd be better off by backbuffering as soon as you have more than say 2 or 3 rectangles. I wonder if this is problematic or not... I'd say yes. It is a huge calling overhead, even if clipping is pretty fast. As long as you use HW-accels, you do each accel call mutiple times, which wastes a lot of time unless we do batched accel. Thus I think complex clipping shouldn't be handled by LibGGI2D, as it is rarely needed and it would require the hardware to support method 2 to be able to do accelerated drawing (o.k. - we could dynamically switch drawing functions if multiple clips are active, but that would add a lot of complexity without need). OK. Especially if LibGGI2D is oriented towards hardware acceleration, complex clipping should not be too much different from hardware chipsets capabilities. Yeah. It might make sense to implement a simple z-buffer operations thingy or similar for LibGGI3D and base windowing toolkits on that. Basically that is what they want: Multiple planes stacked on to of each other, with different depth. I think LibGGI2D would mainly be handy for stuff like making stuff like statistics plots or similar for an existing application. Could be very handy for web based dynamic graphics e.g. These applications don't require complex clipping. Hmmm. I'm not so sure... It seems to me that vector oriented programs do a lot of clipping indeed; e.g. against polygonal region (a filled graphic plot). You mean like in filling a figure ? IMHO using clipping to do that is a braindead idea. They should use fillpoly or tesselate the poly and draw triangles. At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. Could you give an API wishlist ? I might attack reimplementing LibGGI2D in a way that makes it more consistent with the other extensions and allowing to HW-Accelerate much of it. implement offscreen windows, and I'll be able to do a dual release of both LibGWT (0.0.2 :-) and OpenAmulet (4.3.51 :-)). GREAT ! CU, ANdy -- Andreas Beck | Email : [EMAIL PROTECTED]
Re: ggi2dDrawArc, ggi2dFillArc
On Tue, 7 Mar 2000, Rodolphe Ortalo wrote: On Sun, 5 Mar 2000, Andreas Beck wrote: (as an answer to this question from myself) Should libggi2d support arbitrary clipping - or would it be acceptable to have a 'small' version with only rectangular clipping ? (But with decent drawing functions.) I don't think LibGGI2D should have arbitrary clipping. I'd leave that to a windowing library or a 3D package. I understand. But I asked this question in the first place because I don't feel totally at ease with the way I/we do clipping over regions (set-of-non-overlapping-rectangles) in LibGWT. I have the feeling of initiating too much workload wrt to graphic context switch. (Basically, the way it is done is a loop over all the rectangles composing the region while calling set-GC ; draw .) Ugh. IMHO you should define a function which sets up the clip regions however you want to represent them, and then have the target code decompose that into a set-GC ; draw loop, or a stencil mask, or a set of GL clip planes, or whatever. You will lose all your optimization potential if you hardcode the clipping algorithm as you describe above. I wonder if this is problematic or not... I think it is. I only know about 2 hardware clipping implementations: 1. single rectangle nad 2. z-buffer or window-id (which is essentially the same except for the comparision function). Thus I think complex clipping shouldn't be handled by LibGGI2D, as it is rarely needed and it would require the hardware to support method 2 to be able to do accelerated drawing (o.k. - we could dynamically switch drawing functions if multiple clips are active, but that would add a lot of complexity without need). OK. Especially if LibGGI2D is oriented towards hardware acceleration, complex clipping should not be too much different from hardware chipsets capabilities. Right, like alpha/z/stencil tests or window IDs |-. I think LibGGI2D would mainly be handy for stuff like making stuff like statistics plots or similar for an existing application. Could be very handy for web based dynamic graphics e.g. These applications don't require complex clipping. Hmmm. I'm not so sure... It seems to me that vector oriented programs do a lot of clipping indeed; e.g. against polygonal region (a filled graphic plot). GL clip planes. Well, we'll see. Anyway, I still think that libxmi may be an interesting candidate for a GGI sub-lib. It would surely raise problems wrt hardware acceleration - so not for LibGGI2D in the first place - but it may be nice to have a decent set of drawing functions. (libxmi is a legacy extracted from the public X11 sources - it is used in gnuplot according to the documentation. It provides all the usual drawing functions of X11 - but it is a software oriented rendering package in the first place [maybe even in the design itself]). I actually think this is a much better idea than LibGGI2D itself. LibXMI has a specific purpose and welldefined boundaries to its design, whereas LibGGI2D's design is much more generic and ill-defined. Thus, it should be easy to turn LibXMI into a LibGGI extension and accelerate its operations in the appropriate target code, and we'd always know where we stood and what functionality to support. Contrast this with LibGGI2D, where we cannot agree even on what functionality should be present in the library API itself, to say nothing of how to accelerate it! I think that says a lot. I don't know these issues much. I'd like to have additional advice from people knowing GGI. At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. And this will hopefully be very soon: I mainly need to understand why libgwt's evExpose events gets messed by OpenAmulet currently, and to implement offscreen windows, and I'll be able to do a dual release of both LibGWT (0.0.2 :-) and OpenAmulet (4.3.51 :-)). Sounds good! Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: ggi2dDrawArc, ggi2dFillArc
On Sun, 5 Mar 2000, Andreas Beck wrote: (as an answer to this question from myself) Should libggi2d support arbitrary clipping - or would it be acceptable to have a 'small' version with only rectangular clipping ? (But with decent drawing functions.) I don't think LibGGI2D should have arbitrary clipping. I'd leave that to a windowing library or a 3D package. I understand. But I asked this question in the first place because I don't feel totally at ease with the way I/we do clipping over regions (set-of-non-overlapping-rectangles) in LibGWT. I have the feeling of initiating too much workload wrt to graphic context switch. (Basically, the way it is done is a loop over all the rectangles composing the region while calling set-GC ; draw .) I wonder if this is problematic or not... I only know about 2 hardware clipping implementations: 1. single rectangle nad 2. z-buffer or window-id (which is essentially the same except for the comparision function). Thus I think complex clipping shouldn't be handled by LibGGI2D, as it is rarely needed and it would require the hardware to support method 2 to be able to do accelerated drawing (o.k. - we could dynamically switch drawing functions if multiple clips are active, but that would add a lot of complexity without need). OK. Especially if LibGGI2D is oriented towards hardware acceleration, complex clipping should not be too much different from hardware chipsets capabilities. I think LibGGI2D would mainly be handy for stuff like making stuff like statistics plots or similar for an existing application. Could be very handy for web based dynamic graphics e.g. These applications don't require complex clipping. Hmmm. I'm not so sure... It seems to me that vector oriented programs do a lot of clipping indeed; e.g. against polygonal region (a filled graphic plot). Well, we'll see. Anyway, I still think that libxmi may be an interesting candidate for a GGI sub-lib. It would surely raise problems wrt hardware acceleration - so not for LibGGI2D in the first place - but it may be nice to have a decent set of drawing functions. (libxmi is a legacy extracted from the public X11 sources - it is used in gnuplot according to the documentation. It provides all the usual drawing functions of X11 - but it is a software oriented rendering package in the first place [maybe even in the design itself]). I don't know these issues much. I'd like to have additional advice from people knowing GGI. At least, I know I will need _exactly_ these drawing functions to have _all_ the rendering capabilities required for the OpenAmulet GUI library. And this will hopefully be very soon: I mainly need to understand why libgwt's evExpose events gets messed by OpenAmulet currently, and to implement offscreen windows, and I'll be able to do a dual release of both LibGWT (0.0.2 :-) and OpenAmulet (4.3.51 :-)). Rodolphe
Re: ggi2dDrawArc, ggi2dFillArc
On Thu, 2 Mar 2000, Eric , Yu-En Lue wrote: Should potential connections (to do, considered, already done) between libxmi and libggi2d be explored further ? it's algorithms , data structures are mostly done and rather imcompatible with ggi , I don't know how clipping works , but I guess incorporating it into libggi2d may require some efforts.. especially taking care of the region/clipping parts... Should libggi2d support arbitrary clipping - or would it be acceptable to have a 'small' version with only rectangular clipping ? (But with decent drawing functions.) libxmi is more a sort of vector-drawing rasterizer package than a full set of image manipulation functions - but well, it could be useful to have such a thing. Well, anyway, more on this later, Rodolphe
Re: ggi2dDrawArc, ggi2dFillArc
Hi ! I am not a GGI-newbie anymore but fairly 'young' in it. I recently was trying to use the above functions without any success. I am running a late January snapshot of all ggi including ggi2d. AFAIK the development of LibGGI2D is pretty much halted ... Anyone here who takes care of it ? If no one does right now, is there someone who would _want_ to take care of it ? IMHO it could take a complete rewrite ... According to the ChangeLog in libggi2d/doc and the TODO, these two functions are open issues. Has there been any work on it in the mean time? AFAIK not. I would be very thankful if somebody could help me since this work is to replace X in a commercial, embedded product; I and probably quite some other developers here are available for commercial contract work, if required. We will of course also try to help without payment as time permits. The above two functions should be relatively trivial to add, just a bit of a pain regarding the number of special cases to handle. I'd basically handle it the same as drawing the full ellipse and just checking if the angle is within the specified range. CU, Andy -- = Andreas Beck| Email : [EMAIL PROTECTED] =
Re: ggi2dDrawArc, ggi2dFillArc
On Wed, 1 Mar 2000, Rodolphe Ortalo wrote: Just a note, I recently fell around GNU 'libxmi' which seems to be "the drawing functions of X11 stand-alone" (available from your nearest www.gnu.org site). It's pretty small and covers much of X11 drawing aspects (but only the algorithms, nothing more)... Clipping things are not available ... others are mostly done . :)) Should potential connections (to do, considered, already done) between libxmi and libggi2d be explored further ? it's algorithms , data structures are mostly done and rather imcompatible with ggi , I don't know how clipping works , but I guess incorporating it into libggi2d may require some efforts.. especially taking care of the region/clipping parts... Rodolphe
Re: ggi2dDrawArc, ggi2dFillArc
Andreas, first, thank you and the other guys for the hints. I'll look into libxmi. I and probably quite some other developers here are available for commercial contract work, if required. Thank you for the offer and I'll relay that to our 'CTO' right away! thomas -- === Thomas Mittelstaedt, Software Developer [EMAIL PROTECTED]
